# Implementation Plan: Custom Task Status Management - [x] 1. Database schema and migration - Add `custom_task_statuses` JSON column to Project model - Create migration script to add the column with default empty array - Update Task model to change status from Enum to String type - Test migration on development database - _Requirements: 6.1, 6.2, 6.3, 9.1_ - [x] 2. Backend: Create Pydantic schemas for custom task statuses - Create `backend/schemas/custom_task_status.py` with all schema classes - Implement `CustomTaskStatus`, `CustomTaskStatusCreate`, `CustomTaskStatusUpdate` schemas - Implement `CustomTaskStatusReorder`, `CustomTaskStatusDelete` schemas - Implement `AllTaskStatusesResponse`, `TaskStatusInUseError` schemas - Add validation for status name uniqueness and color format - _Requirements: 1.3, 1.4, 2.4_ - [x] 3. Backend: Implement GET endpoint for retrieving all task statuses - Add `get_all_task_statuses` endpoint to `backend/routers/projects.py` - Return both system statuses and custom statuses - Include default status identification - Ensure project access validation - _Requirements: 1.1, 9.2_ - [x] 4. Backend: Implement POST endpoint for creating custom status - Add `create_custom_task_status` endpoint to `backend/routers/projects.py` - Validate status name uniqueness within project - Auto-assign color from palette if not provided - Generate unique status ID - Add status to project's custom_task_statuses JSON array - Use `flag_modified` for JSON column updates - _Requirements: 1.2, 1.3, 1.4_ - [x] 5. Backend: Implement PUT endpoint for updating custom status - Add `update_custom_task_status` endpoint to `backend/routers/projects.py` - Support updating name, color, and is_default flag - Validate name uniqueness if name is changed - If setting as default, unset other default statuses - Use `flag_modified` for JSON column updates - _Requirements: 2.1, 2.2, 2.3, 5.2_ - [x] 6. Backend: Implement DELETE endpoint for deleting custom status - Add `delete_custom_task_status` endpoint to `backend/routers/projects.py` - Check if status is in use by any tasks - If in use, return error with task count and IDs - Support optional reassignment of tasks to another status - If deleting default status, auto-assign new default - Prevent deletion of last status - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_ - [x] 7. Backend: Implement PATCH endpoint for reordering statuses - Add `reorder_custom_task_statuses` endpoint to `backend/routers/projects.py` - Accept ordered list of status IDs - Validate all status IDs are present - Update order field for each status - Use `flag_modified` for JSON column updates - _Requirements: 4.1, 4.2, 4.3, 4.4_ - [x] 8. Backend: Update task endpoints to support custom statuses - Modify task creation to use default status if not specified - Update task status validation to check both system and custom statuses - Ensure status resolution works across project boundaries - Update bulk status update endpoint to validate custom statuses - _Requirements: 5.3, 6.4, 6.5, 10.1, 10.2_ - [ ]* 8.1 Write unit tests for custom status CRUD operations - Test creating status with and without color - Test updating status name and color - Test deleting unused status - Test deleting status with task reassignment - Test reordering statuses - Test default status management - Test validation errors (duplicate names, invalid colors) - _Requirements: 1.1-1.5, 2.1-2.5, 3.1-3.5, 4.1-4.5, 5.1-5.5_ - [ ]* 8.2 Write property test for status name uniqueness - **Property 1: Status name uniqueness within project** - **Validates: Requirements 1.3, 2.4** - [ ]* 8.3 Write property test for color format validity - **Property 2: Status color format validity** - **Validates: Requirements 1.4** - [ ]* 8.4 Write property test for default status uniqueness - **Property 3: Default status uniqueness** - **Validates: Requirements 5.2** - [ ]* 8.5 Write property test for status order consistency - **Property 5: Status order consistency** - **Validates: Requirements 4.1, 4.3** - [x] 9. Checkpoint - Ensure all backend tests pass - Ensure all tests pass, ask the user if questions arise. - [x] 10. Frontend: Create custom task status service - Create `frontend/src/services/customTaskStatus.ts` - Implement `getAllStatuses` method - Implement `createStatus` method - Implement `updateStatus` method - Implement `deleteStatus` method - Implement `reorderStatuses` method - Add TypeScript interfaces for all request/response types - _Requirements: 1.1, 1.2, 2.1, 3.1, 4.1_ - [x] 11. Frontend: Create CustomTaskStatusManager component - Create `frontend/src/components/settings/CustomTaskStatusManager.vue` - Implement status list display with system and custom statuses - Add visual indicators for default status - Display task count for each status - Add "Add Status" button - Implement loading and error states - _Requirements: 1.1, 8.1, 8.2, 8.3_ - [x] 12. Frontend: Implement Add/Edit status dialog - Add dialog for creating new status - Add dialog for editing existing status - Implement status name input with validation - Implement color picker with predefined palette - Show live preview of status badge - Display validation errors inline - Handle save and cancel actions - _Requirements: 1.2, 1.3, 1.4, 2.1, 2.2, 2.3_ - [x] 13. Frontend: Implement status deletion with confirmation - Add delete button for each custom status - Show confirmation dialog with task count - If status in use, show reassignment dropdown - Implement reassignment logic - Handle deletion success and errors - Update UI after deletion - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_ - [x] 14. Frontend: Implement drag-and-drop reordering - Install and configure vue-draggable-next library - Add drag handles to status items - Implement drag-and-drop functionality - Call reorder API on drop - Update UI optimistically - Handle reorder errors - _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_ - [x] 15. Frontend: Implement default status management - Add "Set as Default" button/toggle for each status - Show visual indicator for default status - Update default status via API - Ensure only one default at a time - _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_ - [x] 16. Frontend: Integrate CustomTaskStatusManager into ProjectSettingsView - Add CustomTaskStatusManager to Tasks tab in ProjectSettingsView - Position it above or below existing task type manager - Add separator between sections - Ensure proper layout and spacing - _Requirements: 1.1_ - [x] 17. Frontend: Update TaskStatusBadge component for custom colors - Modify `frontend/src/components/task/TaskStatusBadge.vue` - Accept status object with color property - Apply custom background color from status - Calculate contrast color for text (black or white) - Maintain existing styling for system statuses - _Requirements: 7.1, 7.2, 7.3_ - [x] 18. Frontend: Update EditableTaskStatus component for custom statuses - Modify `frontend/src/components/task/EditableTaskStatus.vue` - Fetch custom statuses for current project - Display both system and custom statuses in dropdown - Show color indicator next to each status option - Update task status via API - _Requirements: 7.1, 7.2, 7.3, 7.4_ - [x] 19. Frontend: Update TaskStatusFilter component for custom statuses - Modify `frontend/src/components/asset/TaskStatusFilter.vue` - Modify `frontend/src/components/shot/ShotTaskStatusFilter.vue` - Include custom statuses in filter options - Show color indicators in filter dropdown - Apply filters correctly with custom statuses - _Requirements: 7.4_ - [x] 20. Frontend: Update bulk status update to support custom statuses - Modify `frontend/src/components/task/TaskBulkActionsMenu.vue` - Fetch custom statuses for current project - Include custom statuses in bulk update dropdown - Validate all selected tasks are from same project - Show color indicators in dropdown - _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5_ - [ ] 21. Frontend: Ensure status updates reflect immediately across UI - Implement reactive status updates in Pinia store - Update all components displaying statuses when status changes - Test status color changes reflect without page refresh - Test status name changes reflect without page refresh - _Requirements: 2.3, 7.5_ - [ ]* 21.1 Write E2E test for creating and using custom status - Create custom status via UI - Assign custom status to a task - Verify status displays with correct color - _Requirements: 1.1-1.5, 7.1-7.5_ - [ ]* 21.2 Write E2E test for editing status and verifying UI updates - Edit status name and color - Verify all instances update without refresh - _Requirements: 2.1-2.5, 7.5_ - [ ]* 21.3 Write E2E test for deleting status with reassignment - Create status and assign to tasks - Delete status with reassignment - Verify tasks updated correctly - _Requirements: 3.1-3.5_ - [ ]* 21.4 Write E2E test for drag-and-drop reordering - Reorder statuses via drag-and-drop - Verify order persists after refresh - _Requirements: 4.1-4.5_ - [ ] 22. Checkpoint - Ensure all tests pass - Ensure all tests pass, ask the user if questions arise. - [ ] 23. Testing: Verify backward compatibility with existing tasks - Test that existing tasks with system statuses still work - Test that system statuses are always available - Test status resolution for both system and custom statuses - Test project isolation (custom statuses don't leak between projects) - _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 9.1, 9.2, 9.3, 9.4, 9.5_ - [ ] 24. Documentation: Update API documentation - Document all new custom status endpoints in Swagger/OpenAPI - Add examples for request/response payloads - Document error responses - Update README with feature description - [ ] 25. Final integration testing and bug fixes - Test complete workflow: create project → add statuses → create tasks → use statuses - Test edge cases: deleting last status, concurrent modifications, etc. - Test across different user roles (admin, coordinator, artist) - Fix any bugs discovered during testing - Verify all acceptance criteria are met