feat: complete issue fixes and implement remaining features

## Critical Issues (CRIT-001~003) - All Fixed
- JWT secret key validation with pydantic field_validator
- Login audit logging for success/failure attempts
- Frontend API path prefix removal

## High Priority Issues (HIGH-001~008) - All Fixed
- Project soft delete using is_active flag
- Redis session token bytes handling
- Rate limiting with slowapi (5 req/min for login)
- Attachment API permission checks
- Kanban view with drag-and-drop
- Workload heatmap UI (WorkloadPage, WorkloadHeatmap)
- TaskDetailModal integrating Comments/Attachments
- UserSelect component for task assignment

## Medium Priority Issues (MED-001~012) - All Fixed
- MED-001~005: DB commits, N+1 queries, datetime, error format, blocker flag
- MED-006: Project health dashboard (HealthService, ProjectHealthPage)
- MED-007: Capacity update API (PUT /api/users/{id}/capacity)
- MED-008: Schedule triggers (cron parsing, deadline reminders)
- MED-009: Watermark feature (image/PDF watermarking)
- MED-010~012: useEffect deps, DOM operations, PDF export

## New Files
- backend/app/api/health/ - Project health API
- backend/app/services/health_service.py
- backend/app/services/trigger_scheduler.py
- backend/app/services/watermark_service.py
- backend/app/core/rate_limiter.py
- frontend/src/pages/ProjectHealthPage.tsx
- frontend/src/components/ProjectHealthCard.tsx
- frontend/src/components/KanbanBoard.tsx
- frontend/src/components/WorkloadHeatmap.tsx

## Tests
- 113 new tests passing (health: 32, users: 14, triggers: 35, watermark: 32)

## OpenSpec Archives
- add-project-health-dashboard
- add-capacity-update-api
- add-schedule-triggers
- add-watermark-feature
- add-rate-limiting
- enhance-frontend-ux
- add-resource-management-ui

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
beabigegg
2026-01-04 21:49:52 +08:00
parent 64874d5425
commit 9b220523ff
90 changed files with 9426 additions and 194 deletions

View File

@@ -41,6 +41,18 @@
- **WHEN** 任務同時滿足兩個條件
- **THEN** 觸發器被觸發
#### Scenario: Cron 表達式觸發
- **GIVEN** 觸發器設定為 cron 表達式 (如 `0 9 * * 1` 每週一早上 9 點)
- **WHEN** 系統時間匹配 cron 表達式
- **THEN** 系統評估並執行該觸發器
- **AND** 記錄執行結果至 trigger_logs
#### Scenario: 截止日期提醒
- **GIVEN** 觸發器設定為「截止日前 N 天提醒」
- **WHEN** 任務距離截止日剩餘 N 天
- **THEN** 系統發送提醒通知給任務指派者
- **AND** 每個任務每個提醒設定只觸發一次
### Requirement: Trigger Actions
系統 SHALL 支援多種觸發動作類型。

View File

@@ -3,9 +3,7 @@
## Purpose
文件管理系統,提供檔案附件、版本控制、加密存儲與浮水印功能。
## Requirements
### Requirement: File Attachments
系統 SHALL 支援任務層級的檔案附件,儲存於地端 NAS。
@@ -73,7 +71,7 @@
系統 SHALL 在下載時自動為檔案加上使用者浮水印。
#### Scenario: 圖片浮水印
- **GIVEN** 使用者下載圖片類型附件
- **GIVEN** 使用者下載圖片類型附件 (PNG, JPG, JPEG)
- **WHEN** 系統處理下載請求
- **THEN** 自動加上包含使用者姓名、工號、下載時間的浮水印
- **AND** 浮水印位置不影響主要內容
@@ -93,6 +91,18 @@
- 下載日期時間
- 機密等級標示(如適用)
#### Scenario: 不支援的檔案類型
- **GIVEN** 使用者下載非圖片/PDF 類型附件
- **WHEN** 系統處理下載請求
- **THEN** 直接提供原始檔案下載
- **AND** 不嘗試加上浮水印
#### Scenario: 浮水印服務異常處理
- **GIVEN** 浮水印生成過程發生錯誤
- **WHEN** 系統無法完成浮水印處理
- **THEN** 記錄錯誤日誌
- **AND** 提供原始檔案下載(降級處理)
### Requirement: Audit Trail
系統 SHALL 記錄所有文件操作供稽核追溯。

View File

@@ -50,6 +50,18 @@
- **THEN** `load_percentage` 顯示為 `null`
- **AND** `load_level` 顯示為 `unavailable`
#### Scenario: 容量更新 API
- **GIVEN** 管理者需要更新團隊成員的容量
- **WHEN** 管理者呼叫 `PUT /api/users/{user_id}/capacity` 並提供新容量值
- **THEN** 系統驗證容量值在有效範圍內 (0-168 小時)
- **AND** 更新使用者的 capacity 欄位
- **AND** 記錄變更至稽核日誌
#### Scenario: 容量更新權限控制
- **GIVEN** 一般使用者嘗試更新他人容量
- **WHEN** 使用者呼叫 `PUT /api/users/{other_id}/capacity`
- **THEN** 系統拒絕請求並回傳 403 Forbidden
### Requirement: Multi-Project Health Dashboard
系統 SHALL 提供多專案健康看板,讓主管一覽所有專案狀態。
@@ -65,6 +77,18 @@
- **THEN** 該專案標示為延遲狀態
- **AND** 顯示延遲任務數量與影響
#### Scenario: 專案健康 API
- **GIVEN** 後端系統運行中
- **WHEN** 客戶端請求 `GET /api/projects/health`
- **THEN** 系統回傳所有可存取專案的健康數據
- **AND** 包含 `total_tasks`, `completed_tasks`, `overdue_tasks`, `blocked_tasks`, `risk_score`
#### Scenario: 單一專案健康詳情
- **GIVEN** 主管需要查看特定專案詳情
- **WHEN** 客戶端請求 `GET /api/projects/{id}/health`
- **THEN** 系統回傳該專案的詳細健康數據
- **AND** 包含任務分類統計與風險評估
### Requirement: Team Workload Distribution
系統 SHALL 提供團隊工作分配查詢功能。
@@ -99,6 +123,31 @@
- **WHEN** 查詢其他部門使用者的負載
- **THEN** 系統拒絕存取並回傳 403 Forbidden
### Requirement: Workload Heatmap UI
The system SHALL provide a visual workload heatmap interface for managers.
#### Scenario: View workload heatmap
- **GIVEN** user is logged in as manager or admin
- **WHEN** user navigates to /workload page
- **THEN** system displays a heatmap showing all accessible users' workload
- **AND** each user cell is color-coded by load level (green/yellow/red)
#### Scenario: Navigate between weeks
- **GIVEN** user is viewing the workload page
- **WHEN** user clicks previous/next week buttons
- **THEN** the heatmap updates to show that week's workload data
#### Scenario: View user workload details
- **GIVEN** user is viewing the workload heatmap
- **WHEN** user clicks on a specific user's cell
- **THEN** a modal/drawer opens showing that user's task breakdown
- **AND** tasks show title, project, time estimate, and due date
#### Scenario: Filter by department
- **GIVEN** user is a system admin
- **WHEN** user selects a department from the filter
- **THEN** the heatmap shows only users from that department
## Data Model
```

View File

@@ -3,9 +3,7 @@
## Purpose
任務管理核心系統,支援多層級架構、自定義欄位與多維視角。
## Requirements
### Requirement: Hierarchical Task Structure
系統 SHALL 支援多層級任務架構:空間 (Space) > 專案 (Project) > 任務 (Task) > 子任務 (Sub-task)。
@@ -102,6 +100,63 @@
- **THEN** 系統記錄並計算剩餘時間
- **AND** 更新資源負載統計
### Requirement: Kanban View
The system SHALL provide a Kanban board view for tasks with drag-and-drop status management.
#### Scenario: View Kanban board
- **GIVEN** user is on the Tasks page
- **WHEN** user selects Kanban view
- **THEN** tasks are displayed in columns grouped by status
- **AND** each column header shows the status name and task count
#### Scenario: Drag task to change status
- **GIVEN** user is viewing the Kanban board
- **WHEN** user drags a task card to a different status column
- **THEN** the task status is updated via API
- **AND** the card moves to the new column
- **AND** other users viewing the board see the update
#### Scenario: View toggle persistence
- **GIVEN** user switches to Kanban view
- **WHEN** user navigates away and returns
- **THEN** the Kanban view is still selected
### Requirement: Task Detail Modal
The system SHALL provide a task detail modal with comments and attachments.
#### Scenario: Open task detail
- **GIVEN** user is viewing tasks in any view
- **WHEN** user clicks on a task
- **THEN** a modal opens showing task details
- **AND** the modal includes comments section
- **AND** the modal includes attachments section
#### Scenario: Edit task in modal
- **GIVEN** user has task detail modal open
- **WHEN** user modifies task fields and saves
- **THEN** the task is updated via API
- **AND** the task list/board reflects the changes
### Requirement: Task Assignment UI
The system SHALL allow assigning tasks to users during creation and editing.
#### Scenario: Assign task during creation
- **GIVEN** user is creating a new task
- **WHEN** user selects an assignee from the dropdown
- **THEN** the task is created with the selected assignee
#### Scenario: Change task assignee
- **GIVEN** user has task detail modal open
- **WHEN** user changes the assignee
- **THEN** the task assignee is updated
- **AND** the new assignee receives a notification
#### Scenario: Set due date and time estimate
- **GIVEN** user is creating or editing a task
- **WHEN** user sets due date and time estimate
- **THEN** the values are saved with the task
- **AND** the task appears on the appropriate date in calendar view
## Data Model
```

View File

@@ -3,9 +3,7 @@
## Purpose
使用者認證與授權系統,透過外部認證 API 進行身份驗證,提供細部權限控制。
## Requirements
### Requirement: API-Based Authentication
系統 SHALL 限定使用外部認證 API (https://pj-auth-api.vercel.app) 進行登入認證,不支援其他認證方式。
@@ -91,6 +89,25 @@
- **WHEN** 使用者執行登出操作
- **THEN** 系統銷毀 session 並清除 token
### Requirement: API Rate Limiting
The system SHALL implement rate limiting to protect against brute force attacks and DoS attempts.
#### Scenario: Login rate limit enforcement
- **GIVEN** a client IP has made 5 login attempts within 1 minute
- **WHEN** the client attempts another login
- **THEN** the system returns HTTP 429 Too Many Requests
- **AND** the response includes a Retry-After header
#### Scenario: Rate limit window reset
- **GIVEN** a client has exceeded the rate limit
- **WHEN** the rate limit window expires (1 minute)
- **THEN** the client can make new requests
#### Scenario: Rate limit per IP
- **GIVEN** rate limiting is IP-based
- **WHEN** different IPs make requests
- **THEN** each IP has its own rate limit counter
## Data Model
```