feat: Implement project templates feature

[pqhung3007]

This commit adds a comprehensive project templates feature that allows users to create, manage, and use reusable project templates.

Backend Changes:

• Add ProjectTemplate model with fields for template configuration, optional features, and content
• Create serializers for template CRUD operations with validation
• Implement API views for template management (list, create, update, delete, use)
• Add URL routes for template endpoints at /api/workspaces/{slug}/project-templates/
• Create database migration for project_templates table with unique constraints

Frontend Changes:

• Add TypeScript types for IProjectTemplate and related interfaces
• Create ProjectTemplateService for API interactions
• Implement MobX store (ProjectTemplateStore) for state management
• Add templates route to workspace settings navigation
• Create templates page with list view, search, and empty state
• Build ProjectTemplateCard component for displaying templates
• Implement CreateProjectTemplateModal for template creation

Features:

• Create reusable project templates with customizable properties
• Configure optional features (modules, cycles, pages, issue types, etc.)
• Support for custom states, labels, issue types, and initial work items
• Track template usage statistics
• Search and filter templates
• Delete templates with confirmation
• Professional empty states and UI components

This implementation follows the existing codebase patterns for consistency and maintainability.

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Improvement (change that would cause existing functionality to not work as expected)
• Code refactoring
• Performance improvements
• Documentation update

Screenshots and Media (if applicable)

Test Scenarios

References

To fix the problem, we need to stop exposing the raw error message (str(e)) from IntegrityError exceptions to the API client in the default case. Instead, we should return a generic, non-descript message (such as "A database error occurred") for any unhandled database errors, and optionally log the real error on the server side for debugging/tracing. No change is needed to error cases already handled (such as unique constraints or workspace existence). This requires:

• Updating the except IntegrityError as e block to return a generic message for unhandled cases (line 102), instead of relaying str(e) to users.
• Optionally, adding a server-side log message (using either print or Python’s logging module; choose logging if not shown otherwise).
• No new imports needed — logging is in the standard library, and the rest of the code does not show a preferred logging approach.

All changes are restricted to apps/api/plane/api/views/project_template.py, specifically the relevant lines in the post method of ProjectTemplateListCreateAPIEndpoint.

To fix the issue, we should avoid returning stringified exceptions directly to the user for unexpected errors, and instead return a generic error message that reveals no internal details. Specific, non-sensitive error messages for expected exceptions like IntegrityError and Workspace.DoesNotExist should be kept. For the generic Exception catch block (lines 110-114), modify the response so it returns a generic error message (e.g., "An internal server error occurred.") instead of the actual exception message. Optionally, log the actual exception (not shown in the snippet), but do not expose the details in the API response.

The changes needed are:

• Edit the except Exception as e: block (lines 110-114) to return a generic error message in the response.

No new imports are needed as we are not adding logging or other custom behavior.

---

To fix this issue in apps/api/plane/api/views/project_template.py (specifically in the patch method), the error response at line 182 should be made generic and not include the string representation of the integrity error. Instead of returning {"error": str(e)}, respond with a generic message such as {"error": "Invalid request"} or another appropriate, non-revealing message. Also, ensure proper server-side logging is present to retain the exception details for debugging (if logging is implemented locally). No new imports are required. Only the error response in the patch method under generic IntegrityError needs to be changed.