3bdc6ff1c9
## Security Enhancements (P0) - Add input validation with max_length and numeric range constraints - Implement WebSocket token authentication via first message - Add path traversal prevention in file storage service ## Permission Enhancements (P0) - Add project member management for cross-department access - Implement is_department_manager flag for workload visibility ## Cycle Detection (P0) - Add DFS-based cycle detection for task dependencies - Add formula field circular reference detection - Display user-friendly cycle path visualization ## Concurrency & Reliability (P1) - Implement optimistic locking with version field (409 Conflict on mismatch) - Add trigger retry mechanism with exponential backoff (1s, 2s, 4s) - Implement cascade restore for soft-deleted tasks ## Rate Limiting (P1) - Add tiered rate limits: standard (60/min), sensitive (20/min), heavy (5/min) - Apply rate limits to tasks, reports, attachments, and comments ## Frontend Improvements (P1) - Add responsive sidebar with hamburger menu for mobile - Improve touch-friendly UI with proper tap target sizes - Complete i18n translations for all components ## Backend Reliability (P2) - Configure database connection pool (size=10, overflow=20) - Add Redis fallback mechanism with message queue - Add blocker check before task deletion ## API Enhancements (P3) - Add standardized response wrapper utility - Add /health/ready and /health/live endpoints - Implement project templates with status/field copying ## Tests Added - test_input_validation.py - Schema and path traversal tests - test_concurrency_reliability.py - Optimistic locking and retry tests - test_backend_reliability.py - Connection pool and Redis tests - test_api_enhancements.py - Health check and template tests Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
47 lines
1.9 KiB
Markdown
47 lines
1.9 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Storage Path Validation
|
|
The system SHALL validate file storage configuration on startup to ensure reliability.
|
|
|
|
#### Scenario: Valid NAS storage path
|
|
- **WHEN** application starts with valid UPLOAD_DIR configuration
|
|
- **THEN** system verifies path exists and is writable
|
|
- **THEN** system logs confirmation of storage configuration
|
|
|
|
#### Scenario: Invalid storage path
|
|
- **WHEN** application starts with invalid or inaccessible UPLOAD_DIR
|
|
- **THEN** system logs error with specific issue (not found, not writable)
|
|
- **THEN** system falls back to local storage with warning
|
|
|
|
#### Scenario: Storage health check
|
|
- **WHEN** health check endpoint is called
|
|
- **THEN** response includes storage availability status
|
|
- **THEN** response includes available disk space if accessible
|
|
|
|
### Requirement: Notification Delivery Reliability
|
|
The system SHALL ensure notification delivery even during temporary Redis failures.
|
|
|
|
#### Scenario: Redis temporarily unavailable
|
|
- **WHEN** Redis publish fails due to connection error
|
|
- **THEN** system queues message in local memory
|
|
- **WHEN** Redis connection recovers
|
|
- **THEN** system retries queued messages
|
|
|
|
#### Scenario: Queue overflow prevention
|
|
- **WHEN** local message queue exceeds maximum size
|
|
- **THEN** oldest messages are dropped
|
|
- **THEN** system logs warning about dropped messages
|
|
|
|
### Requirement: Task Deletion Safety
|
|
The system SHALL warn users when deleting tasks with unresolved blockers.
|
|
|
|
#### Scenario: Delete task with active blockers
|
|
- **WHEN** user attempts to delete task with unresolved blockers
|
|
- **THEN** system returns warning with blocker count
|
|
- **THEN** user must confirm or use force_delete flag
|
|
|
|
#### Scenario: Force delete with blockers
|
|
- **WHEN** user force deletes task with blockers
|
|
- **THEN** system auto-resolves all blockers with "task deleted" reason
|
|
- **THEN** system proceeds with task deletion
|