125 lines
8.4 KiB
Markdown
125 lines
8.4 KiB
Markdown
# Requirements Document
|
|
|
|
## Introduction
|
|
|
|
This specification defines the refactoring of the TaskBrowser component to extract the data table into a separate, reusable component (TasksDataTable) and redesign the selection behavior to provide a more robust and maintainable bulk selection system for task status updates and assignments.
|
|
|
|
## Glossary
|
|
|
|
- **TaskBrowser**: The parent component that manages task filtering, toolbar, and detail panel display
|
|
- **TasksDataTable**: The new extracted component that handles table rendering, selection, and row interactions
|
|
- **Selection State**: The set of currently selected task rows, tracked by task IDs
|
|
- **Bulk Actions**: Operations performed on multiple selected tasks simultaneously (status update, assignment)
|
|
- **Context Menu**: Right-click menu that appears when user right-clicks on selected rows
|
|
- **Row Selection**: The mechanism for selecting one or more table rows using click, Shift+click, Ctrl+click, or select-all checkbox
|
|
|
|
## Requirements
|
|
|
|
### Requirement 1: Extract Data Table Component
|
|
|
|
**User Story:** As a developer, I want the data table logic separated from the TaskBrowser component, so that the code is more maintainable and the table can be reused in other contexts.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the TaskBrowser component is refactored THEN the system SHALL create a new TasksDataTable component that encapsulates all table rendering logic
|
|
2. WHEN the TasksDataTable component is created THEN the system SHALL move all TanStack Table configuration, column definitions, and table rendering from TaskBrowser to TasksDataTable
|
|
3. WHEN the TasksDataTable receives filtered tasks as props THEN the system SHALL render the table with all existing columns and sorting functionality
|
|
4. WHEN the TaskBrowser uses TasksDataTable THEN the system SHALL pass filtered tasks, column visibility, and event handlers as props
|
|
5. WHEN a user interacts with the table THEN the system SHALL emit events from TasksDataTable to TaskBrowser for row clicks, double-clicks, and context menu actions
|
|
|
|
### Requirement 2: Redesign Selection State Management
|
|
|
|
**User Story:** As a developer, I want selection state managed with a clearer index-based approach, so that bulk operations are more reliable and easier to debug.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the selection system is redesigned THEN the system SHALL maintain selection state using task IDs as the primary key
|
|
2. WHEN tasks are filtered or sorted THEN the system SHALL preserve valid selections and remove selections for tasks no longer in the filtered set
|
|
3. WHEN the TasksDataTable manages selection THEN the system SHALL expose selected task IDs through an emitted event or v-model binding
|
|
4. WHEN selection state changes THEN the system SHALL emit a selection-change event with the array of selected task IDs
|
|
5. WHEN the parent component needs selected tasks THEN the system SHALL compute the selected tasks array from the selection state and filtered tasks
|
|
|
|
### Requirement 3: Implement Robust Row Selection Behavior
|
|
|
|
**User Story:** As a user, I want intuitive row selection with keyboard modifiers, so that I can efficiently select multiple tasks for bulk operations.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a user clicks a row without modifiers THEN the system SHALL clear all selections and select only the clicked row
|
|
2. WHEN a user Ctrl+clicks (or Cmd+clicks on Mac) a row THEN the system SHALL toggle that row's selection state without affecting other selections
|
|
3. WHEN a user Shift+clicks a row THEN the system SHALL select all rows between the last clicked row and the current row
|
|
4. WHEN a user clicks the header checkbox THEN the system SHALL toggle selection of all visible (filtered) rows
|
|
5. WHEN a user double-clicks a row THEN the system SHALL open the task detail panel without modifying selection state
|
|
|
|
### Requirement 4: Preserve Selection During Context Menu Operations
|
|
|
|
**User Story:** As a user, I want my selection preserved when I right-click and perform bulk actions, so that I can perform multiple operations on the same set of tasks.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a user right-clicks a selected row THEN the system SHALL preserve the current selection and show the context menu
|
|
2. WHEN a user right-clicks an unselected row THEN the system SHALL add that row to the selection and show the context menu
|
|
3. WHEN a user performs a bulk action from the context menu THEN the system SHALL preserve the selection after the operation completes
|
|
4. WHEN a user closes the context menu without performing an action THEN the system SHALL preserve the current selection
|
|
5. WHEN a bulk operation fails THEN the system SHALL preserve the selection so the user can retry
|
|
|
|
### Requirement 5: Clear Selection on Filter Changes
|
|
|
|
**User Story:** As a user, I want selections cleared when I change filters, so that I don't accidentally perform bulk operations on tasks I can no longer see.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a user changes the status filter THEN the system SHALL clear all row selections
|
|
2. WHEN a user changes the type filter THEN the system SHALL clear all row selections
|
|
3. WHEN a user changes the episode filter THEN the system SHALL clear all row selections
|
|
4. WHEN a user changes the assignee filter THEN the system SHALL clear all row selections
|
|
5. WHEN a user changes the search query THEN the system SHALL clear all row selections
|
|
|
|
### Requirement 6: Maintain Visual Selection Feedback
|
|
|
|
**User Story:** As a user, I want clear visual feedback on which rows are selected, so that I know which tasks will be affected by bulk operations.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a row is selected THEN the system SHALL apply a distinct background color to the row
|
|
2. WHEN multiple rows are selected THEN the system SHALL apply the same background color to all selected rows
|
|
3. WHEN the user hovers over a row THEN the system SHALL show a hover state that is visually distinct from the selection state
|
|
4. WHEN the header checkbox is in an indeterminate state THEN the system SHALL display the checkbox with an indeterminate visual indicator
|
|
5. WHEN all visible rows are selected THEN the system SHALL display the header checkbox as fully checked
|
|
|
|
### Requirement 7: Support Bulk Status Updates
|
|
|
|
**User Story:** As a user, I want to update the status of multiple selected tasks at once, so that I can efficiently manage task workflows.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a user selects multiple tasks and chooses a status from the context menu THEN the system SHALL update all selected tasks to the chosen status
|
|
2. WHEN a bulk status update succeeds THEN the system SHALL display a success toast showing the count of updated tasks
|
|
3. WHEN a bulk status update completes THEN the system SHALL refresh the task list to show updated statuses
|
|
4. WHEN a bulk status update fails THEN the system SHALL display an error toast and preserve the selection
|
|
5. WHEN a bulk status update is in progress THEN the system SHALL show a loading indicator
|
|
|
|
### Requirement 8: Support Bulk Task Assignment
|
|
|
|
**User Story:** As a user, I want to assign multiple selected tasks to a team member at once, so that I can efficiently distribute work.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN a user selects multiple tasks and chooses an assignee from the context menu THEN the system SHALL assign all selected tasks to the chosen user
|
|
2. WHEN a bulk assignment succeeds THEN the system SHALL display a success toast showing the count of assigned tasks
|
|
3. WHEN a bulk assignment completes THEN the system SHALL refresh the task list to show updated assignees
|
|
4. WHEN a bulk assignment fails THEN the system SHALL display an error toast and preserve the selection
|
|
5. WHEN a bulk assignment is in progress THEN the system SHALL show a loading indicator
|
|
|
|
### Requirement 9: Maintain Existing TaskBrowser Features
|
|
|
|
**User Story:** As a user, I want all existing TaskBrowser features to continue working after the refactor, so that my workflow is not disrupted.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN the refactor is complete THEN the system SHALL maintain all existing filtering capabilities (status, type, episode, assignee, context, search)
|
|
2. WHEN the refactor is complete THEN the system SHALL maintain the task detail panel functionality for both desktop and mobile views
|
|
3. WHEN the refactor is complete THEN the system SHALL maintain column visibility controls and persistence
|
|
4. WHEN the refactor is complete THEN the system SHALL maintain sorting functionality on all sortable columns
|
|
5. WHEN the refactor is complete THEN the system SHALL maintain the task count and selection count display
|