egg/PROJECT-CONTORL
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ed8d30e9bd0b28190a9f67d4354a9c3bba1087bb
PROJECT-CONTORL/openspec/specs/dashboard/spec.md
beabigegg 35c90fe76b feat: implement 5 QA-driven security and quality proposals 
Implemented proposals from comprehensive QA review:

1. extend-csrf-protection
   - Add POST to CSRF protected methods in frontend
   - Global CSRF middleware for all state-changing operations
   - Update tests with CSRF token fixtures

2. tighten-cors-websocket-security
   - Replace wildcard CORS with explicit method/header lists
   - Disable query parameter auth in production (code 4002)
   - Add per-user WebSocket connection limit (max 5, code 4005)

3. shorten-jwt-expiry
   - Reduce JWT expiry from 7 days to 60 minutes
   - Add refresh token support with 7-day expiry
   - Implement token rotation on refresh
   - Frontend auto-refresh when token near expiry (<5 min)

4. fix-frontend-quality
   - Add React.lazy() code splitting for all pages
   - Fix useCallback dependency arrays (Dashboard, Comments)
   - Add localStorage data validation in AuthContext
   - Complete i18n for AttachmentUpload component

5. enhance-backend-validation
   - Add SecurityAuditMiddleware for access denied logging
   - Add ErrorSanitizerMiddleware for production error messages
   - Protect /health/detailed with admin authentication
   - Add input length validation (comment 5000, desc 10000)

All 521 backend tests passing. Frontend builds successfully.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-12 23:19:05 +08:00

214 lines
7.7 KiB
Markdown
Raw Blame History

# 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: Code Splitting
The application SHALL use code splitting with React.lazy() to reduce initial bundle size and improve load times.
#### Scenario: Initial page load
- **WHEN** user navigates to application
- **THEN** only core framework and current route are loaded
- **AND** other routes are loaded on demand
#### Scenario: Route-based splitting
- **WHEN** user navigates to a different page
- **THEN** that page's code chunk is loaded dynamically
- **AND** loading fallback is displayed during load
### Requirement: LocalStorage Data Validation
User data loaded from localStorage SHALL be validated before use to prevent crashes from corrupted data.
#### Scenario: Corrupted localStorage data
- **WHEN** localStorage contains malformed user JSON
- **THEN** invalid data is cleared
- **AND** user is redirected to login page
- **AND** no application crash occurs
#### Scenario: Valid localStorage data
- **WHEN** localStorage contains valid user JSON
- **THEN** user is authenticated from stored data
- **AND** application loads normally
### 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
Reference in New Issue View Git Blame Copy Permalink