Init Repo
This commit is contained in:
@@ -0,0 +1,341 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user