679b89ae4c
Security Validation (enhance-security-validation): - JWT secret validation with entropy checking and pattern detection - CSRF protection middleware with token generation/validation - Frontend CSRF token auto-injection for DELETE/PUT/PATCH requests - MIME type validation with magic bytes detection for file uploads Error Resilience (add-error-resilience): - React ErrorBoundary component with fallback UI and retry functionality - ErrorBoundaryWithI18n wrapper for internationalization support - Page-level and section-level error boundaries in App.tsx Query Performance (optimize-query-performance): - Query monitoring utility with threshold warnings - N+1 query fixes using joinedload/selectinload - Optimized project members, tasks, and subtasks endpoints Bug Fixes: - WebSocket session management (P0): Return primitives instead of ORM objects - LIKE query injection (P1): Escape special characters in search queries Tests: 543 backend tests, 56 frontend tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
187 lines
6.7 KiB
Markdown
187 lines
6.7 KiB
Markdown
# dashboard Specification
|
|
|
|
## Purpose
|
|
TBD - created by archiving change add-dashboard-widgets. Update Purpose after archive.
|
|
## Requirements
|
|
### Requirement: Dashboard Statistics
|
|
|
|
The system SHALL display aggregated statistics showing the user's task overview.
|
|
|
|
#### Scenario: User views task statistics
|
|
- Given: User is authenticated
|
|
- When: User navigates to Dashboard
|
|
- Then: System displays:
|
|
- Total tasks assigned to user
|
|
- Tasks due this week
|
|
- Overdue tasks count
|
|
- Completion rate percentage
|
|
|
|
### Requirement: My Workload Widget
|
|
|
|
The system SHALL display the current user's workload summary for the current week.
|
|
|
|
#### Scenario: User views personal workload
|
|
- Given: User is authenticated
|
|
- When: User views Dashboard
|
|
- Then: System displays:
|
|
- Allocated hours vs capacity hours
|
|
- Load percentage with visual indicator
|
|
- Load level status (normal/warning/overloaded)
|
|
|
|
### Requirement: Project Health Summary
|
|
|
|
The system SHALL display an aggregated project health summary.
|
|
|
|
#### Scenario: User views project health overview
|
|
- Given: User is authenticated
|
|
- When: User views Dashboard
|
|
- Then: System displays:
|
|
- Total projects count
|
|
- Healthy/At-Risk/Critical breakdown
|
|
- Average health score
|
|
- Projects with blockers count
|
|
|
|
### Requirement: Quick Actions
|
|
|
|
The system SHALL provide quick navigation links to common actions.
|
|
|
|
#### Scenario: User accesses quick actions
|
|
- Given: User is authenticated
|
|
- When: User views Dashboard
|
|
- Then: System displays navigation links to:
|
|
- Spaces page
|
|
- Workload page
|
|
- Project Health page
|
|
- (Admin only) Audit page
|
|
|
|
### Requirement: Dashboard API Endpoint
|
|
|
|
The backend SHALL provide a single aggregated endpoint for dashboard data.
|
|
|
|
#### Scenario: Frontend fetches dashboard data
|
|
- Given: User is authenticated
|
|
- When: Frontend requests GET /api/dashboard
|
|
- Then: Backend returns:
|
|
- User task statistics
|
|
- Current week workload summary
|
|
- Project health summary
|
|
- And: Response is optimized with single database query where possible
|
|
|
|
### Requirement: Responsive Layout
|
|
The system SHALL provide a responsive user interface that adapts to different screen sizes for optimal usability.
|
|
|
|
#### Scenario: Mobile sidebar behavior
|
|
- **WHEN** user accesses application on mobile device (width < 768px)
|
|
- **THEN** sidebar is hidden by default
|
|
- **THEN** hamburger menu button is visible in header
|
|
- **WHEN** user taps hamburger menu
|
|
- **THEN** sidebar slides in from left with backdrop overlay
|
|
|
|
#### Scenario: Table responsive behavior
|
|
- **WHEN** user views task list on small screen
|
|
- **THEN** table displays with horizontal scroll or switches to card layout
|
|
- **THEN** all essential information remains accessible
|
|
|
|
#### Scenario: Touch-friendly interactions
|
|
- **WHEN** user interacts with application on touch device
|
|
- **THEN** all interactive elements have minimum 44x44 pixel tap targets
|
|
- **THEN** sufficient spacing prevents accidental taps
|
|
|
|
### Requirement: Complete Internationalization
|
|
The system SHALL support complete internationalization with no hardcoded text strings.
|
|
|
|
#### Scenario: Language switching
|
|
- **WHEN** user changes language preference
|
|
- **THEN** all UI text updates to selected language
|
|
- **THEN** no untranslated strings remain visible
|
|
|
|
#### Scenario: Date and time localization
|
|
- **WHEN** dates and times are displayed
|
|
- **THEN** format follows user's locale preference
|
|
- **THEN** relative times (e.g., "2 hours ago") are properly translated
|
|
|
|
#### Scenario: New component text
|
|
- **WHEN** new UI components are added
|
|
- **THEN** all text strings use i18n translation keys
|
|
- **THEN** translations exist for all supported locales
|
|
|
|
### Requirement: Standardized API Response Format
|
|
The system SHALL return all API responses in a consistent standardized format.
|
|
|
|
#### Scenario: Successful API response
|
|
- **WHEN** API request succeeds
|
|
- **THEN** response includes success=true
|
|
- **THEN** response includes data field with result
|
|
- **THEN** response includes timestamp field
|
|
|
|
#### Scenario: Error API response
|
|
- **WHEN** API request fails
|
|
- **THEN** response includes success=false
|
|
- **THEN** response includes error_code field
|
|
- **THEN** response includes message field with description
|
|
|
|
### Requirement: API Versioning
|
|
The system SHALL support API versioning to enable backwards compatibility during upgrades.
|
|
|
|
#### Scenario: Versioned API endpoint
|
|
- **WHEN** client calls /api/v1/tasks
|
|
- **THEN** system routes to current version implementation
|
|
- **THEN** response works with v1 client expectations
|
|
|
|
#### Scenario: Legacy API route
|
|
- **WHEN** client calls /api/tasks (unversioned)
|
|
- **THEN** system routes to default version
|
|
- **THEN** response includes deprecation warning header
|
|
|
|
### Requirement: Comprehensive Health Check
|
|
The system SHALL provide detailed health check endpoints for monitoring.
|
|
|
|
#### Scenario: All systems healthy
|
|
- **WHEN** health check is called and all dependencies are available
|
|
- **THEN** response includes status=healthy
|
|
- **THEN** response includes checks object with database=ok, redis=ok
|
|
|
|
#### Scenario: Partial system failure
|
|
- **WHEN** health check is called and Redis is unavailable
|
|
- **THEN** response includes status=degraded
|
|
- **THEN** response includes checks object with database=ok, redis=error
|
|
|
|
### Requirement: Project Templates
|
|
The system SHALL support project templates to standardize project creation.
|
|
|
|
#### Scenario: Create project from template
|
|
- **WHEN** user creates project selecting a template
|
|
- **THEN** system copies TaskStatus definitions from template
|
|
- **THEN** system copies CustomField definitions from template
|
|
- **THEN** project is created with predefined structure
|
|
|
|
#### Scenario: Save project as template
|
|
- **WHEN** user saves existing project as template
|
|
- **THEN** system creates template with project's TaskStatus definitions
|
|
- **THEN** system creates template with project's CustomField definitions
|
|
- **THEN** template is available for future project creation
|
|
|
|
### Requirement: Error Boundary Protection
|
|
The frontend application SHALL gracefully handle component render errors without crashing the entire application.
|
|
|
|
#### Scenario: Component error contained
|
|
- **WHEN** a render error occurs in a dashboard widget
|
|
- **THEN** only that widget SHALL display an error state
|
|
- **AND** other widgets SHALL continue to function normally
|
|
|
|
#### Scenario: User-friendly error display
|
|
- **WHEN** a component fails to render
|
|
- **THEN** users SHALL see a friendly error message
|
|
- **AND** users SHALL have an option to retry or report the issue
|
|
|
|
#### Scenario: Error logging
|
|
- **WHEN** a render error is caught by an Error Boundary
|
|
- **THEN** the error details SHALL be logged for debugging
|
|
- **AND** error context (component stack) SHALL be captured
|
|
|
|
#### Scenario: Recovery option
|
|
- **WHEN** a user sees an error fallback UI
|
|
- **AND** the user clicks "Retry"
|
|
- **THEN** the failed component SHALL attempt to re-render
|
|
|