feat: implement 8 OpenSpec proposals for security, reliability, and UX improvements
## 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>
This commit is contained in:
beabigegg
@@ -0,0 +1,18 @@
|
||||
# Change: Add API Enhancements and Future-Proofing
|
||||
|
||||
## Why
|
||||
To improve API maintainability and prepare for future growth: standardize API response format for consistent client handling, add API versioning for backwards compatibility, enhance health check for better monitoring, and add project templates for improved user productivity.
|
||||
|
||||
## What Changes
|
||||
- Implement standardized API response wrapper
|
||||
- Add API version prefix (/api/v1/)
|
||||
- Enhance health check with database and Redis status
|
||||
- Add project template feature for creating projects from templates
|
||||
|
||||
## Impact
|
||||
- Affected specs: dashboard
|
||||
- Affected code:
|
||||
- `backend/app/main.py` - API versioning, health check
|
||||
- `backend/app/core/response.py` - Response wrapper (new)
|
||||
- `backend/app/models/project_template.py` - Template model (new)
|
||||
- `backend/app/api/projects/router.py` - Template endpoints
|
||||
@@ -0,0 +1,57 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,35 @@
|
||||
# Tasks: Add API Enhancements
|
||||
|
||||
## 1. API Response Standardization
|
||||
- [x] 1.1 Create response wrapper utility class
|
||||
- [x] 1.2 Define standard response structure {success, data, message, timestamp}
|
||||
- [x] 1.3 Create error response format with error_code field
|
||||
- [x] 1.4 Apply wrapper to sample endpoints for validation (deferred - breaking change, use incrementally)
|
||||
- [x] 1.5 Document response format in API docs (documented in code comments)
|
||||
|
||||
## 2. API Versioning
|
||||
- [x] 2.1 Add /api/v1/ prefix to all routes
|
||||
- [x] 2.2 Update frontend API base URL configuration
|
||||
- [x] 2.3 Keep /api/ routes as alias during transition
|
||||
- [x] 2.4 Add deprecation headers to old routes
|
||||
|
||||
## 3. Enhanced Health Check
|
||||
- [x] 3.1 Add database connectivity check
|
||||
- [x] 3.2 Add Redis connectivity check
|
||||
- [x] 3.3 Add scheduler status check
|
||||
- [x] 3.4 Return detailed status object with check results
|
||||
- [x] 3.5 Add /health/ready and /health/live endpoints
|
||||
|
||||
## 4. Project Templates
|
||||
- [x] 4.1 Create ProjectTemplate model with fields
|
||||
- [x] 4.2 Create database migration
|
||||
- [x] 4.3 Add template CRUD API endpoints
|
||||
- [x] 4.4 Implement "create project from template" endpoint
|
||||
- [x] 4.5 Copy TaskStatus and CustomField definitions from template
|
||||
- [x] 4.6 Add frontend template selection in project creation
|
||||
|
||||
## 5. Testing
|
||||
- [x] 5.1 Test standardized response format
|
||||
- [x] 5.2 Test API version routing
|
||||
- [x] 5.3 Test enhanced health check scenarios
|
||||
- [x] 5.4 Test project template creation flow
|
||||
@@ -0,0 +1,18 @@
|
||||
# Change: Add Backend Reliability Improvements
|
||||
|
||||
## Why
|
||||
Several backend reliability issues need addressing: database connection pool may be undersized for production load, Redis publish failures have no fallback mechanism, tasks with active blockers can be deleted without warning, and NAS storage configuration needs validation.
|
||||
|
||||
## What Changes
|
||||
- Optimize database connection pool configuration
|
||||
- Add local queue fallback for Redis publish failures
|
||||
- Add pre-deletion check for active blockers on tasks
|
||||
- Validate NAS storage path configuration on startup
|
||||
|
||||
## Impact
|
||||
- Affected specs: document-management
|
||||
- Affected code:
|
||||
- `backend/app/core/database.py` - Connection pool config
|
||||
- `backend/app/services/notification_service.py` - Redis fallback
|
||||
- `backend/app/api/tasks/router.py` - Blocker check
|
||||
- `backend/app/services/file_storage_service.py` - NAS validation
|
||||
@@ -0,0 +1,46 @@
|
||||
## 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
|
||||
@@ -0,0 +1,31 @@
|
||||
# Tasks: Add Backend Reliability Improvements
|
||||
|
||||
## 1. Database Connection Pool
|
||||
- [x] 1.1 Add pool_size=10 configuration
|
||||
- [x] 1.2 Add max_overflow=20 configuration
|
||||
- [x] 1.3 Add pool_timeout=30 configuration
|
||||
- [x] 1.4 Add environment variable overrides for pool settings
|
||||
- [x] 1.5 Log connection pool statistics periodically
|
||||
|
||||
## 2. Redis Fallback Mechanism
|
||||
- [x] 2.1 Create in-memory queue for failed Redis publishes
|
||||
- [x] 2.2 Implement background retry for queued messages
|
||||
- [x] 2.3 Add max queue size limit to prevent memory issues
|
||||
- [x] 2.4 Log Redis failures and recovery events
|
||||
|
||||
## 3. Blocker Deletion Check
|
||||
- [x] 3.1 Add check for unresolved blockers before task deletion
|
||||
- [x] 3.2 Return warning response with blocker count
|
||||
- [x] 3.3 Add force_delete parameter to bypass check
|
||||
- [x] 3.4 Auto-resolve blockers when force deleting
|
||||
|
||||
## 4. NAS Storage Validation
|
||||
- [x] 4.1 Validate UPLOAD_DIR path exists on startup
|
||||
- [x] 4.2 Check write permissions on storage directory
|
||||
- [x] 4.3 Log warning if using local storage instead of NAS
|
||||
- [x] 4.4 Add health check endpoint for storage status
|
||||
|
||||
## 5. Testing
|
||||
- [x] 5.1 Test under connection pool exhaustion
|
||||
- [x] 5.2 Test Redis disconnect and recovery
|
||||
- [x] 5.3 Test blocker deletion scenarios
|
||||
@@ -0,0 +1,17 @@
|
||||
# Change: Add Concurrency Handling and Reliability Improvements
|
||||
|
||||
## Why
|
||||
Multiple users editing the same task simultaneously can lead to lost updates (last-write-wins). Trigger execution failures are not retried, causing permanent failures on transient errors. Soft-delete restore operation does not cascade to child tasks, leading to data inconsistency.
|
||||
|
||||
## What Changes
|
||||
- Implement optimistic locking using version field for task updates
|
||||
- Add retry mechanism with exponential backoff for trigger execution
|
||||
- Implement cascade restore for soft-deleted tasks and their children
|
||||
|
||||
## Impact
|
||||
- Affected specs: task-management, automation
|
||||
- Affected code:
|
||||
- `backend/app/models/task.py` - Add version field
|
||||
- `backend/app/api/tasks/router.py` - Optimistic locking logic
|
||||
- `backend/app/services/trigger_scheduler.py` - Retry mechanism
|
||||
- `backend/app/api/tasks/router.py` - Cascade restore
|
||||
@@ -0,0 +1,21 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Trigger Execution Retry
|
||||
The system SHALL retry failed trigger executions with exponential backoff to handle transient failures.
|
||||
|
||||
#### Scenario: Trigger succeeds after retry
|
||||
- **WHEN** trigger execution fails due to transient error
|
||||
- **THEN** system retries after 1 second delay
|
||||
- **WHEN** retry succeeds
|
||||
- **THEN** trigger is marked as successful in execution log
|
||||
|
||||
#### Scenario: Trigger exhausts retries
|
||||
- **WHEN** trigger execution fails 3 consecutive times
|
||||
- **THEN** system marks trigger execution as permanently failed
|
||||
- **THEN** system sends alert notification to system administrators
|
||||
- **THEN** execution log contains all retry attempts with error details
|
||||
|
||||
#### Scenario: Non-retryable error
|
||||
- **WHEN** trigger fails with validation or permission error (4xx)
|
||||
- **THEN** system does not retry and marks as failed immediately
|
||||
- **THEN** error is logged with appropriate categorization
|
||||
@@ -0,0 +1,30 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Optimistic Locking for Task Updates
|
||||
The system SHALL use optimistic locking to prevent concurrent update conflicts on tasks.
|
||||
|
||||
#### Scenario: Concurrent update detected
|
||||
- **WHEN** user A and user B both load task at version 1
|
||||
- **WHEN** user A saves changes, incrementing version to 2
|
||||
- **WHEN** user B attempts to save with version 1
|
||||
- **THEN** system returns 409 Conflict error
|
||||
- **THEN** error message instructs user to refresh and retry
|
||||
|
||||
#### Scenario: Sequential updates succeed
|
||||
- **WHEN** user loads task at version N
|
||||
- **WHEN** user saves changes with correct version N
|
||||
- **THEN** system accepts update and increments version to N+1
|
||||
|
||||
### Requirement: Soft Delete Cascade Restore
|
||||
The system SHALL restore child tasks when parent task is restored from soft delete.
|
||||
|
||||
#### Scenario: Parent task restored with children
|
||||
- **WHEN** soft-deleted parent task is restored
|
||||
- **THEN** system identifies child tasks deleted at same timestamp
|
||||
- **THEN** system recursively restores all matching child tasks
|
||||
- **THEN** audit log records restoration of parent and children
|
||||
|
||||
#### Scenario: Selective restore without children
|
||||
- **WHEN** user explicitly requests restore without cascade
|
||||
- **THEN** only parent task is restored
|
||||
- **THEN** child tasks remain in deleted state
|
||||
@@ -0,0 +1,29 @@
|
||||
# Tasks: Add Concurrency Handling and Reliability Improvements
|
||||
|
||||
## 1. Optimistic Locking
|
||||
- [x] 1.1 Add `version` integer field to Task model with default=1
|
||||
- [x] 1.2 Create database migration for version field
|
||||
- [x] 1.3 Include version in TaskResponse schema
|
||||
- [x] 1.4 Modify update_task to accept and validate version
|
||||
- [x] 1.5 Return 409 Conflict when version mismatch detected
|
||||
- [x] 1.6 Auto-increment version on successful update
|
||||
- [x] 1.7 Update frontend to send version with update requests
|
||||
- [x] 1.8 Handle 409 Conflict in frontend with user notification
|
||||
|
||||
## 2. Trigger Retry Mechanism
|
||||
- [x] 2.1 Add retry configuration (max_retries=3, base_delay=1s)
|
||||
- [x] 2.2 Implement exponential backoff (1s, 2s, 4s)
|
||||
- [x] 2.3 Log each retry attempt with attempt number
|
||||
- [x] 2.4 Mark trigger as permanently failed after max retries
|
||||
- [x] 2.5 Send alert notification when trigger exhausts retries
|
||||
|
||||
## 3. Soft Delete Cascade Restore
|
||||
- [x] 3.1 Modify restore_task to find all child tasks deleted at same time
|
||||
- [x] 3.2 Recursively restore child tasks with matching deleted_at timestamp
|
||||
- [x] 3.3 Add option to restore only parent vs cascade restore
|
||||
- [x] 3.4 Log restore operations in audit trail
|
||||
|
||||
## 4. Testing
|
||||
- [x] 4.1 Test concurrent updates with version conflict
|
||||
- [x] 4.2 Test trigger retry on transient failure
|
||||
- [x] 4.3 Test cascade restore of parent with children
|
||||
@@ -0,0 +1,18 @@
|
||||
# Change: Add Cycle Detection for Task Dependencies and Formula Fields
|
||||
|
||||
## Why
|
||||
The system currently lacks detection for circular references in task dependencies and custom field formulas. This can lead to infinite loops during Gantt chart rendering or formula calculation, potentially causing application crashes or stack overflow errors.
|
||||
|
||||
## What Changes
|
||||
- Implement cycle detection algorithm (DFS/BFS) for task dependencies
|
||||
- Add cycle detection for formula field references
|
||||
- Return descriptive error when cycle is detected
|
||||
- Prevent saving of configurations that would create cycles
|
||||
|
||||
## Impact
|
||||
- Affected specs: task-management, automation
|
||||
- Affected code:
|
||||
- `backend/app/services/dependency_service.py` - Task dependency validation
|
||||
- `backend/app/services/formula_service.py` - Formula reference validation
|
||||
- `backend/app/api/task-dependencies/router.py` - API validation
|
||||
- `backend/app/api/custom-fields/router.py` - Field validation
|
||||
@@ -0,0 +1,18 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Formula Field Cycle Prevention
|
||||
The system SHALL detect and prevent circular references in custom field formulas to avoid infinite calculation loops.
|
||||
|
||||
#### Scenario: Formula self-reference rejected
|
||||
- **WHEN** user creates a formula field that references itself
|
||||
- **THEN** system rejects with 400 Bad Request
|
||||
- **THEN** error message indicates self-reference is not allowed
|
||||
|
||||
#### Scenario: Formula circular reference chain rejected
|
||||
- **WHEN** user creates formula where Field A references Field B and Field B references Field A
|
||||
- **THEN** system rejects with 400 Bad Request
|
||||
- **THEN** error message includes the reference cycle path
|
||||
|
||||
#### Scenario: Valid formula references accepted
|
||||
- **WHEN** user creates formula referencing other fields without cycles
|
||||
- **THEN** system saves the formula and calculates values correctly
|
||||
@@ -0,0 +1,19 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Task Dependency Cycle Prevention
|
||||
The system SHALL detect and prevent circular dependencies between tasks to ensure Gantt charts can be properly rendered.
|
||||
|
||||
#### Scenario: Direct circular dependency rejected
|
||||
- **WHEN** user attempts to create dependency where Task A depends on Task B and Task B depends on Task A
|
||||
- **THEN** system rejects the operation with 400 Bad Request
|
||||
- **THEN** error message includes the cycle path (e.g., "Circular dependency detected: A -> B -> A")
|
||||
|
||||
#### Scenario: Indirect circular dependency rejected
|
||||
- **WHEN** user attempts to create dependency that would form a cycle (A -> B -> C -> A)
|
||||
- **THEN** system rejects the operation with 400 Bad Request
|
||||
- **THEN** error message includes the full cycle path
|
||||
|
||||
#### Scenario: Valid dependency chain accepted
|
||||
- **WHEN** user creates dependencies forming a valid DAG (directed acyclic graph)
|
||||
- **THEN** system accepts and saves the dependencies
|
||||
- **THEN** Gantt chart renders correctly with proper task ordering
|
||||
@@ -0,0 +1,23 @@
|
||||
# Tasks: Add Cycle Detection
|
||||
|
||||
## 1. Task Dependency Cycle Detection
|
||||
- [x] 1.1 Implement DFS-based cycle detection algorithm in dependency_service.py
|
||||
- [x] 1.2 Add validation hook when creating/updating task dependencies
|
||||
- [x] 1.3 Return 400 Bad Request with cycle path details when detected
|
||||
- [x] 1.4 Add cycle detection check in bulk dependency operations
|
||||
|
||||
## 2. Formula Field Cycle Detection
|
||||
- [x] 2.1 Parse formula field references to build dependency graph
|
||||
- [x] 2.2 Implement cycle detection for formula field references
|
||||
- [x] 2.3 Add validation when saving custom field formulas
|
||||
- [x] 2.4 Return descriptive error showing the cycle path
|
||||
|
||||
## 3. Frontend Feedback
|
||||
- [x] 3.1 Display user-friendly error message when cycle detected
|
||||
- [x] 3.2 Optionally highlight the problematic dependencies in UI
|
||||
|
||||
## 4. Testing
|
||||
- [x] 4.1 Add unit tests for cycle detection algorithm
|
||||
- [x] 4.2 Test direct circular dependency (A -> B -> A)
|
||||
- [x] 4.3 Test indirect circular dependency (A -> B -> C -> A)
|
||||
- [x] 4.4 Test formula field circular references
|
||||
@@ -0,0 +1,18 @@
|
||||
# Change: Add Frontend Responsive Design and i18n Completion
|
||||
|
||||
## Why
|
||||
The current frontend has usability issues on mobile and tablet devices - sidebar doesn't collapse properly, tables overflow, and some UI elements are not touch-friendly. Additionally, internationalization (i18n) is incomplete with some hardcoded Chinese text remaining in components.
|
||||
|
||||
## What Changes
|
||||
- Implement responsive sidebar with collapsible behavior on small screens
|
||||
- Add responsive table handling with horizontal scroll or card view
|
||||
- Complete i18n translation coverage for all UI text
|
||||
- Improve touch targets for mobile usability
|
||||
|
||||
## Impact
|
||||
- Affected specs: dashboard
|
||||
- Affected code:
|
||||
- `frontend/src/components/Layout.tsx` - Responsive sidebar
|
||||
- `frontend/src/components/*.tsx` - Responsive styles
|
||||
- `frontend/src/i18n/locales/*.json` - Translation files
|
||||
- `frontend/src/pages/*.tsx` - Replace hardcoded text
|
||||
@@ -0,0 +1,39 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,30 @@
|
||||
# Tasks: Add Frontend Improvements
|
||||
|
||||
## 1. Responsive Sidebar
|
||||
- [x] 1.1 Add hamburger menu button for mobile screens
|
||||
- [x] 1.2 Implement slide-out sidebar behavior on small screens
|
||||
- [x] 1.3 Add overlay backdrop when sidebar is open on mobile
|
||||
- [x] 1.4 Persist sidebar state preference in local storage
|
||||
|
||||
## 2. Responsive Tables
|
||||
- [x] 2.1 Add horizontal scroll wrapper for wide tables
|
||||
- [x] 2.2 Implement card view alternative for task lists on mobile
|
||||
- [x] 2.3 Make table columns prioritized (hide less important on small screens)
|
||||
- [x] 2.4 Ensure touch-friendly row actions
|
||||
|
||||
## 3. Touch-Friendly UI
|
||||
- [x] 3.1 Increase tap target sizes to minimum 44x44 pixels
|
||||
- [x] 3.2 Add proper spacing between interactive elements
|
||||
- [x] 3.3 Improve drag-and-drop for touch devices on Kanban
|
||||
|
||||
## 4. i18n Completion
|
||||
- [x] 4.1 Audit all components for hardcoded Chinese text
|
||||
- [x] 4.2 Extract remaining strings to translation files
|
||||
- [x] 4.3 Add missing translations for en and zh-TW locales
|
||||
- [x] 4.4 Ensure date/time formatting uses locale settings
|
||||
|
||||
## 5. Testing
|
||||
- [x] 5.1 Test on mobile viewport (375px width)
|
||||
- [x] 5.2 Test on tablet viewport (768px width)
|
||||
- [x] 5.3 Test language switching functionality
|
||||
- [x] 5.4 Verify all text is properly translated
|
||||
@@ -0,0 +1,17 @@
|
||||
# Change: Add Input Validation and Security Enhancements
|
||||
|
||||
## Why
|
||||
Current API endpoints lack comprehensive input validation, exposing the system to potential DoS attacks, database overflow errors, and security vulnerabilities. Additionally, WebSocket authentication tokens are exposed in query parameters which may be logged.
|
||||
|
||||
## What Changes
|
||||
- Add length validation to all Pydantic schema string fields
|
||||
- Add numeric range validation for decimal/integer fields
|
||||
- Enhance WebSocket token handling to avoid query parameter exposure
|
||||
- Strengthen file path traversal protection in file storage service
|
||||
|
||||
## Impact
|
||||
- Affected specs: user-auth
|
||||
- Affected code:
|
||||
- `backend/app/schemas/*.py` - All schema files
|
||||
- `backend/app/api/websocket/router.py` - WebSocket authentication
|
||||
- `backend/app/services/file_storage_service.py` - Path validation
|
||||
@@ -0,0 +1,37 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Input Length Validation
|
||||
The system SHALL enforce maximum length limits on all user-provided string inputs to prevent DoS attacks and database overflow.
|
||||
|
||||
#### Scenario: Task title exceeds maximum length
|
||||
- **WHEN** user submits a task with title longer than 500 characters
|
||||
- **THEN** system returns 422 Validation Error with descriptive message
|
||||
|
||||
#### Scenario: Description field within limits
|
||||
- **WHEN** user submits content with description under 10000 characters
|
||||
- **THEN** system accepts the input and processes normally
|
||||
|
||||
### Requirement: Secure WebSocket Authentication
|
||||
The system SHALL authenticate WebSocket connections without exposing tokens in URL query parameters.
|
||||
|
||||
#### Scenario: WebSocket connection with token in first message
|
||||
- **WHEN** client connects to WebSocket endpoint
|
||||
- **THEN** server waits for authentication message containing JWT token
|
||||
- **THEN** server validates token before accepting further messages
|
||||
|
||||
#### Scenario: WebSocket connection timeout without authentication
|
||||
- **WHEN** client connects but does not send authentication within 10 seconds
|
||||
- **THEN** server closes the connection with appropriate error code
|
||||
|
||||
### Requirement: Path Traversal Protection
|
||||
The system SHALL prevent file path traversal attacks by validating all file paths resolve within the designated storage directory.
|
||||
|
||||
#### Scenario: Path traversal attempt detected
|
||||
- **WHEN** request contains file path with "../" or absolute path outside storage
|
||||
- **THEN** system rejects request and logs security warning
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
#### Scenario: Valid file path within storage
|
||||
- **WHEN** request contains valid relative file path
|
||||
- **THEN** system resolves path and verifies it is within storage directory
|
||||
- **THEN** system processes file operation normally
|
||||
@@ -0,0 +1,24 @@
|
||||
# Tasks: Add Input Validation and Security Enhancements
|
||||
|
||||
## 1. Schema Input Validation
|
||||
- [x] 1.1 Add max_length validation to TaskBase schema (title: 500, description: 10000)
|
||||
- [x] 1.2 Add max_length validation to ProjectBase schema
|
||||
- [x] 1.3 Add max_length validation to SpaceBase schema
|
||||
- [x] 1.4 Add max_length validation to CommentBase schema
|
||||
- [x] 1.5 Add max_length validation to all other schema string fields
|
||||
- [x] 1.6 Add numeric range validation (ge=0, le=max_value) for decimal fields
|
||||
|
||||
## 2. WebSocket Token Security
|
||||
- [x] 2.1 Implement WebSocket authentication via first message instead of query parameter
|
||||
- [x] 2.2 Update frontend WebSocket connection to send token in first message
|
||||
- [x] 2.3 Add server log filtering to mask sensitive query parameters as fallback (N/A - token no longer in query params)
|
||||
|
||||
## 3. File Path Security
|
||||
- [x] 3.1 Add explicit path traversal validation in file_storage_service.py
|
||||
- [x] 3.2 Ensure resolved path is within base directory
|
||||
- [x] 3.3 Add logging for path traversal attempts
|
||||
|
||||
## 4. Testing
|
||||
- [x] 4.1 Add unit tests for input validation edge cases
|
||||
- [x] 4.2 Add security tests for path traversal attempts
|
||||
- [x] 4.3 Test WebSocket authentication flow
|
||||
@@ -0,0 +1,16 @@
|
||||
# Change: Add Permission Enhancements for Manager and Cross-Department Access
|
||||
|
||||
## Why
|
||||
Department managers cannot view their subordinates' workload data, preventing effective resource allocation decisions. Additionally, cross-department project collaboration is hindered because project members from other departments may be denied access.
|
||||
|
||||
## What Changes
|
||||
- Enable department managers to view workload data of their department members
|
||||
- Add project membership model to support cross-department collaboration
|
||||
- Enhance access control to check project membership in addition to department
|
||||
|
||||
## Impact
|
||||
- Affected specs: resource-management
|
||||
- Affected code:
|
||||
- `backend/app/api/workload/router.py` - Manager access logic
|
||||
- `backend/app/middleware/auth.py` - Access control checks
|
||||
- `backend/app/models/` - New project_members model (optional)
|
||||
@@ -0,0 +1,31 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Manager Workload Visibility
|
||||
The system SHALL allow department managers to view workload data for all members within their department.
|
||||
|
||||
#### Scenario: Manager views department member workload
|
||||
- **WHEN** a department manager requests workload data for a user in their department
|
||||
- **THEN** system returns the workload data for that user
|
||||
|
||||
#### Scenario: Manager denied access to other department workload
|
||||
- **WHEN** a department manager requests workload data for a user in a different department
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
#### Scenario: Regular user cannot view others' workload
|
||||
- **WHEN** a non-manager user requests workload data for another user
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
### Requirement: Cross-Department Project Membership
|
||||
The system SHALL support explicit project membership to enable cross-department collaboration.
|
||||
|
||||
#### Scenario: Add cross-department member to project
|
||||
- **WHEN** project owner adds a user from another department as project member
|
||||
- **THEN** user gains access to the project regardless of department
|
||||
|
||||
#### Scenario: Project member accesses cross-department project
|
||||
- **WHEN** a project member from another department accesses project resources
|
||||
- **THEN** system grants access based on project membership
|
||||
|
||||
#### Scenario: Non-member denied access despite same department
|
||||
- **WHEN** a user not in project membership list attempts to access confidential project
|
||||
- **THEN** system denies access unless user is in the project's department
|
||||
@@ -0,0 +1,19 @@
|
||||
# Tasks: Add Permission Enhancements
|
||||
|
||||
## 1. Manager Workload Access
|
||||
- [x] 1.1 Add role-based check in workload router for department managers
|
||||
- [x] 1.2 Allow managers to query workload for users in their department
|
||||
- [x] 1.3 Add `is_department_manager` flag or role to user model if not exists
|
||||
- [x] 1.4 Update workload API documentation
|
||||
|
||||
## 2. Cross-Department Project Access
|
||||
- [x] 2.1 Create ProjectMember model for explicit project membership
|
||||
- [x] 2.2 Add database migration for project_members table
|
||||
- [x] 2.3 Update check_project_access() to include project membership check
|
||||
- [x] 2.4 Add API endpoints to manage project members
|
||||
- [x] 2.5 Update frontend to display and manage project members
|
||||
|
||||
## 3. Testing
|
||||
- [x] 3.1 Add tests for manager viewing subordinate workload
|
||||
- [x] 3.2 Add tests for cross-department project member access
|
||||
- [x] 3.3 Test access denied for non-members and non-managers
|
||||
@@ -0,0 +1,17 @@
|
||||
# Change: Expand Rate Limiting to Sensitive API Endpoints
|
||||
|
||||
## Why
|
||||
Currently only the login endpoint has rate limiting. Other sensitive operations (task creation, report generation, bulk operations) can be abused through excessive requests, potentially causing service degradation or enabling brute-force attacks.
|
||||
|
||||
## What Changes
|
||||
- Apply rate limiting to task creation/update endpoints
|
||||
- Apply rate limiting to report generation endpoints
|
||||
- Apply rate limiting to bulk operation endpoints
|
||||
- Add configurable rate limit tiers based on endpoint sensitivity
|
||||
|
||||
## Impact
|
||||
- Affected specs: user-auth
|
||||
- Affected code:
|
||||
- `backend/app/api/tasks/router.py` - Task rate limits
|
||||
- `backend/app/api/reports/router.py` - Report rate limits
|
||||
- `backend/app/core/config.py` - Rate limit configuration
|
||||
@@ -0,0 +1,25 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Comprehensive API Rate Limiting
|
||||
The system SHALL enforce rate limits on all sensitive API endpoints to prevent abuse and ensure service availability.
|
||||
|
||||
#### Scenario: Task creation rate limit exceeded
|
||||
- **WHEN** user exceeds 60 task creation requests per minute
|
||||
- **THEN** system returns 429 Too Many Requests
|
||||
- **THEN** response includes Retry-After header
|
||||
|
||||
#### Scenario: Report generation rate limit exceeded
|
||||
- **WHEN** user exceeds 5 report generation requests per minute
|
||||
- **THEN** system returns 429 Too Many Requests
|
||||
- **THEN** response includes rate limit headers
|
||||
|
||||
#### Scenario: Rate limit headers provided
|
||||
- **WHEN** user makes any rate-limited API request
|
||||
- **THEN** response includes X-RateLimit-Limit header
|
||||
- **THEN** response includes X-RateLimit-Remaining header
|
||||
- **THEN** response includes X-RateLimit-Reset header
|
||||
|
||||
#### Scenario: Rate limit window reset
|
||||
- **WHEN** rate limit window expires
|
||||
- **THEN** user can make requests again up to the limit
|
||||
- **THEN** X-RateLimit-Remaining resets to maximum
|
||||
@@ -0,0 +1,30 @@
|
||||
# Tasks: Expand Rate Limiting
|
||||
|
||||
## 1. Configuration
|
||||
- [x] 1.1 Define rate limit tiers in config (standard, sensitive, heavy)
|
||||
- [x] 1.2 Standard: 60/minute, Sensitive: 20/minute, Heavy: 5/minute
|
||||
- [x] 1.3 Add environment variable overrides for rate limits
|
||||
|
||||
## 2. Task API Rate Limiting
|
||||
- [x] 2.1 Apply "standard" rate limit to POST /api/tasks
|
||||
- [x] 2.2 Apply "standard" rate limit to PATCH /api/tasks/{id}
|
||||
- [x] 2.3 Apply "heavy" rate limit to bulk task operations
|
||||
|
||||
## 3. Report API Rate Limiting
|
||||
- [x] 3.1 Apply "heavy" rate limit to POST /api/reports/generate
|
||||
- [x] 3.2 Apply "sensitive" rate limit to report export endpoints
|
||||
|
||||
## 4. Other Sensitive Endpoints
|
||||
- [x] 4.1 Apply "sensitive" rate limit to password change endpoint (N/A - uses external auth)
|
||||
- [x] 4.2 Apply "sensitive" rate limit to attachment upload
|
||||
- [x] 4.3 Apply "standard" rate limit to comment creation
|
||||
|
||||
## 5. Response Headers
|
||||
- [x] 5.1 Include X-RateLimit-Limit header in responses
|
||||
- [x] 5.2 Include X-RateLimit-Remaining header
|
||||
- [x] 5.3 Include X-RateLimit-Reset header
|
||||
|
||||
## 6. Testing
|
||||
- [x] 6.1 Test rate limit enforcement
|
||||
- [x] 6.2 Test rate limit reset after window
|
||||
- [x] 6.3 Verify 429 Too Many Requests response
|
||||
@@ -98,6 +98,43 @@
|
||||
- **THEN** 系統篩選 due_date >= 下週一 且 < 下週日
|
||||
- **AND** 排除已完成狀態的任務
|
||||
|
||||
### Requirement: Formula Field Cycle Prevention
|
||||
The system SHALL detect and prevent circular references in custom field formulas to avoid infinite calculation loops.
|
||||
|
||||
#### Scenario: Formula self-reference rejected
|
||||
- **WHEN** user creates a formula field that references itself
|
||||
- **THEN** system rejects with 400 Bad Request
|
||||
- **THEN** error message indicates self-reference is not allowed
|
||||
|
||||
#### Scenario: Formula circular reference chain rejected
|
||||
- **WHEN** user creates formula where Field A references Field B and Field B references Field A
|
||||
- **THEN** system rejects with 400 Bad Request
|
||||
- **THEN** error message includes the reference cycle path
|
||||
|
||||
#### Scenario: Valid formula references accepted
|
||||
- **WHEN** user creates formula referencing other fields without cycles
|
||||
- **THEN** system saves the formula and calculates values correctly
|
||||
|
||||
### Requirement: Trigger Execution Retry
|
||||
The system SHALL retry failed trigger executions with exponential backoff to handle transient failures.
|
||||
|
||||
#### Scenario: Trigger succeeds after retry
|
||||
- **WHEN** trigger execution fails due to transient error
|
||||
- **THEN** system retries after 1 second delay
|
||||
- **WHEN** retry succeeds
|
||||
- **THEN** trigger is marked as successful in execution log
|
||||
|
||||
#### Scenario: Trigger exhausts retries
|
||||
- **WHEN** trigger execution fails 3 consecutive times
|
||||
- **THEN** system marks trigger execution as permanently failed
|
||||
- **THEN** system sends alert notification to system administrators
|
||||
- **THEN** execution log contains all retry attempts with error details
|
||||
|
||||
#### Scenario: Non-retryable error
|
||||
- **WHEN** trigger fails with validation or permission error (4xx)
|
||||
- **THEN** system does not retry and marks as failed immediately
|
||||
- **THEN** error is logged with appropriate categorization
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -67,3 +67,97 @@ The backend SHALL provide a single aggregated endpoint for dashboard data.
|
||||
- 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
|
||||
|
||||
|
||||
@@ -148,6 +148,51 @@
|
||||
- **THEN** 顯示完整操作歷史
|
||||
- **AND** 支援依時間、操作者、檔案篩選
|
||||
|
||||
### 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
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -148,6 +148,36 @@ The system SHALL provide a visual workload heatmap interface for managers.
|
||||
- **WHEN** user selects a department from the filter
|
||||
- **THEN** the heatmap shows only users from that department
|
||||
|
||||
### Requirement: Manager Workload Visibility
|
||||
The system SHALL allow department managers to view workload data for all members within their department.
|
||||
|
||||
#### Scenario: Manager views department member workload
|
||||
- **WHEN** a department manager requests workload data for a user in their department
|
||||
- **THEN** system returns the workload data for that user
|
||||
|
||||
#### Scenario: Manager denied access to other department workload
|
||||
- **WHEN** a department manager requests workload data for a user in a different department
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
#### Scenario: Regular user cannot view others' workload
|
||||
- **WHEN** a non-manager user requests workload data for another user
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
### Requirement: Cross-Department Project Membership
|
||||
The system SHALL support explicit project membership to enable cross-department collaboration.
|
||||
|
||||
#### Scenario: Add cross-department member to project
|
||||
- **WHEN** project owner adds a user from another department as project member
|
||||
- **THEN** user gains access to the project regardless of department
|
||||
|
||||
#### Scenario: Project member accesses cross-department project
|
||||
- **WHEN** a project member from another department accesses project resources
|
||||
- **THEN** system grants access based on project membership
|
||||
|
||||
#### Scenario: Non-member denied access despite same department
|
||||
- **WHEN** a user not in project membership list attempts to access confidential project
|
||||
- **THEN** system denies access unless user is in the project's department
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -277,6 +277,53 @@ The system SHALL allow assigning tasks to users during creation and editing.
|
||||
- resource_id: 被刪除的專案 ID
|
||||
- changes: [{ field: "is_active", old_value: true, new_value: false }]
|
||||
|
||||
### Requirement: Task Dependency Cycle Prevention
|
||||
The system SHALL detect and prevent circular dependencies between tasks to ensure Gantt charts can be properly rendered.
|
||||
|
||||
#### Scenario: Direct circular dependency rejected
|
||||
- **WHEN** user attempts to create dependency where Task A depends on Task B and Task B depends on Task A
|
||||
- **THEN** system rejects the operation with 400 Bad Request
|
||||
- **THEN** error message includes the cycle path (e.g., "Circular dependency detected: A -> B -> A")
|
||||
|
||||
#### Scenario: Indirect circular dependency rejected
|
||||
- **WHEN** user attempts to create dependency that would form a cycle (A -> B -> C -> A)
|
||||
- **THEN** system rejects the operation with 400 Bad Request
|
||||
- **THEN** error message includes the full cycle path
|
||||
|
||||
#### Scenario: Valid dependency chain accepted
|
||||
- **WHEN** user creates dependencies forming a valid DAG (directed acyclic graph)
|
||||
- **THEN** system accepts and saves the dependencies
|
||||
- **THEN** Gantt chart renders correctly with proper task ordering
|
||||
|
||||
### Requirement: Optimistic Locking for Task Updates
|
||||
The system SHALL use optimistic locking to prevent concurrent update conflicts on tasks.
|
||||
|
||||
#### Scenario: Concurrent update detected
|
||||
- **WHEN** user A and user B both load task at version 1
|
||||
- **WHEN** user A saves changes, incrementing version to 2
|
||||
- **WHEN** user B attempts to save with version 1
|
||||
- **THEN** system returns 409 Conflict error
|
||||
- **THEN** error message instructs user to refresh and retry
|
||||
|
||||
#### Scenario: Sequential updates succeed
|
||||
- **WHEN** user loads task at version N
|
||||
- **WHEN** user saves changes with correct version N
|
||||
- **THEN** system accepts update and increments version to N+1
|
||||
|
||||
### Requirement: Soft Delete Cascade Restore
|
||||
The system SHALL restore child tasks when parent task is restored from soft delete.
|
||||
|
||||
#### Scenario: Parent task restored with children
|
||||
- **WHEN** soft-deleted parent task is restored
|
||||
- **THEN** system identifies child tasks deleted at same timestamp
|
||||
- **THEN** system recursively restores all matching child tasks
|
||||
- **THEN** audit log records restoration of parent and children
|
||||
|
||||
#### Scenario: Selective restore without children
|
||||
- **WHEN** user explicitly requests restore without cascade
|
||||
- **THEN** only parent task is restored
|
||||
- **THEN** child tasks remain in deleted state
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
@@ -108,6 +108,66 @@ The system SHALL implement rate limiting to protect against brute force attacks
|
||||
- **WHEN** different IPs make requests
|
||||
- **THEN** each IP has its own rate limit counter
|
||||
|
||||
### Requirement: Comprehensive API Rate Limiting
|
||||
The system SHALL enforce rate limits on all sensitive API endpoints to prevent abuse and ensure service availability.
|
||||
|
||||
#### Scenario: Task creation rate limit exceeded
|
||||
- **WHEN** user exceeds 60 task creation requests per minute
|
||||
- **THEN** system returns 429 Too Many Requests
|
||||
- **THEN** response includes Retry-After header
|
||||
|
||||
#### Scenario: Report generation rate limit exceeded
|
||||
- **WHEN** user exceeds 5 report generation requests per minute
|
||||
- **THEN** system returns 429 Too Many Requests
|
||||
- **THEN** response includes rate limit headers
|
||||
|
||||
#### Scenario: Rate limit headers provided
|
||||
- **WHEN** user makes any rate-limited API request
|
||||
- **THEN** response includes X-RateLimit-Limit header
|
||||
- **THEN** response includes X-RateLimit-Remaining header
|
||||
- **THEN** response includes X-RateLimit-Reset header
|
||||
|
||||
#### Scenario: Rate limit window reset
|
||||
- **WHEN** rate limit window expires
|
||||
- **THEN** user can make requests again up to the limit
|
||||
- **THEN** X-RateLimit-Remaining resets to maximum
|
||||
|
||||
### Requirement: Input Length Validation
|
||||
The system SHALL enforce maximum length limits on all user-provided string inputs to prevent DoS attacks and database overflow.
|
||||
|
||||
#### Scenario: Task title exceeds maximum length
|
||||
- **WHEN** user submits a task with title longer than 500 characters
|
||||
- **THEN** system returns 422 Validation Error with descriptive message
|
||||
|
||||
#### Scenario: Description field within limits
|
||||
- **WHEN** user submits content with description under 10000 characters
|
||||
- **THEN** system accepts the input and processes normally
|
||||
|
||||
### Requirement: Secure WebSocket Authentication
|
||||
The system SHALL authenticate WebSocket connections without exposing tokens in URL query parameters.
|
||||
|
||||
#### Scenario: WebSocket connection with token in first message
|
||||
- **WHEN** client connects to WebSocket endpoint
|
||||
- **THEN** server waits for authentication message containing JWT token
|
||||
- **THEN** server validates token before accepting further messages
|
||||
|
||||
#### Scenario: WebSocket connection timeout without authentication
|
||||
- **WHEN** client connects but does not send authentication within 10 seconds
|
||||
- **THEN** server closes the connection with appropriate error code
|
||||
|
||||
### Requirement: Path Traversal Protection
|
||||
The system SHALL prevent file path traversal attacks by validating all file paths resolve within the designated storage directory.
|
||||
|
||||
#### Scenario: Path traversal attempt detected
|
||||
- **WHEN** request contains file path with "../" or absolute path outside storage
|
||||
- **THEN** system rejects request and logs security warning
|
||||
- **THEN** system returns 403 Forbidden error
|
||||
|
||||
#### Scenario: Valid file path within storage
|
||||
- **WHEN** request contains valid relative file path
|
||||
- **THEN** system resolves path and verifies it is within storage directory
|
||||
- **THEN** system processes file operation normally
|
||||
|
||||
## Data Model
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user