feat:實作通知系統 — 站內通知、Email 通知、Polling 機制
後端 - 新增 6 個 Notification class（預約建立/確認/拒絕/取消/完成、收到評價），database + mail 雙 channel - 新增 NotificationController（list / unread-count / markRead / markAllRead / destroy） - 整合通知觸發至 MemberBookingController、ProviderBookingController、CompleteFinishedBookings、ReviewController - 新增 notifications / jobs / failed_jobs migration - Docker Compose 加入 queue-worker、mailpit service - DivingOffer 補上 provider() 關聯 前端 - 新增 notificationStore（Polling 30s/60s 自適應 + Page Visibility API） - 新增 NotificationBell（未讀 Badge）、NotificationDrawer（側邊通知中心） - main.js：auth store init 前置於 router.use()，修正 beforeEach guard 時序問題 - notificationAxios：依路徑動態選擇 member/coach token - NotificationDrawer：改用 new URL().pathname 提取 action_url 路徑 OpenSpec - 歸檔 notification-system change - 同步 notification-core / notification-email / notification-triggers specs 至主規格 - 更新 booking-lifecycle / review-lifecycle spec（補充通知觸發 requirement） Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,174 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 通知資料模型
|
||||
|
||||
系統 SHALL 使用 Laravel 內建 `notifications` 資料表儲存站內通知，每筆通知包含：`id`（UUID）、`type`（Notification class 名稱）、`notifiable_type` / `notifiable_id`（多型關聯至 User）、`data`（JSON，含 type / title / body / action_url / related_id / related_type）、`read_at`（nullable）、`created_at` / `updated_at`。
|
||||
|
||||
#### Scenario: 通知建立
|
||||
|
||||
- **WHEN** 業務邏輯觸發 `$user->notify(new XxxNotification(...))`
|
||||
- **THEN** `notifications` 資料表新增一筆記錄，`read_at` 為 null
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 取得通知列表 API
|
||||
|
||||
`GET /api/notifications` SHALL 回傳當前登入使用者的通知列表（含已讀/未讀），分頁 20 筆，依 `created_at` DESC 排序。
|
||||
|
||||
Response data 格式：
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
{
|
||||
"id": "uuid",
|
||||
"type": "booking_confirmed",
|
||||
"title": "預約已確認",
|
||||
"body": "...",
|
||||
"action_url": "http://localhost:5173/my-bookings",
|
||||
"read_at": null,
|
||||
"created_at": "2026-05-17T10:00:00Z"
|
||||
}
|
||||
],
|
||||
"unread_count": 3,
|
||||
"meta": { "current_page": 1, "last_page": 2 }
|
||||
}
|
||||
```
|
||||
|
||||
#### Scenario: 已登入使用者取得通知
|
||||
|
||||
- **WHEN** 已登入 Member 呼叫 `GET /api/notifications`
|
||||
- **THEN** 回傳 `status: true`，`data` 陣列包含該使用者的通知，最新在前
|
||||
|
||||
#### Scenario: 未登入拒絕存取
|
||||
|
||||
- **WHEN** 未帶 Token 呼叫 `GET /api/notifications`
|
||||
- **THEN** 回傳 HTTP 401
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 取得未讀數量 API
|
||||
|
||||
`GET /api/notifications/unread-count` SHALL 回傳當前使用者未讀通知數量，用於 Polling。
|
||||
|
||||
Response：`{ "status": true, "data": { "count": 3 } }`
|
||||
|
||||
#### Scenario: 有未讀通知
|
||||
|
||||
- **WHEN** 使用者有 3 筆 `read_at = null` 的通知時呼叫
|
||||
- **THEN** 回傳 `count: 3`
|
||||
|
||||
#### Scenario: 無未讀通知
|
||||
|
||||
- **WHEN** 所有通知 `read_at` 均不為 null
|
||||
- **THEN** 回傳 `count: 0`
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 標記單一通知為已讀
|
||||
|
||||
`PATCH /api/notifications/{id}/read` SHALL 將指定通知的 `read_at` 設為當前時間。
|
||||
|
||||
#### Scenario: 標記成功
|
||||
|
||||
- **WHEN** 已登入使用者對自己的通知呼叫此 API
|
||||
- **THEN** 回傳 `status: true`，`read_at` 不再為 null
|
||||
|
||||
#### Scenario: 非本人通知拒絕
|
||||
|
||||
- **WHEN** 使用者嘗試標記他人通知
|
||||
- **THEN** 回傳 HTTP 403
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 標記全部通知為已讀
|
||||
|
||||
`PATCH /api/notifications/read-all` SHALL 將當前使用者所有未讀通知一次標記為已讀。
|
||||
|
||||
#### Scenario: 批次標記
|
||||
|
||||
- **WHEN** 使用者有 5 筆未讀，呼叫此 API
|
||||
- **THEN** 所有 5 筆 `read_at` 更新，回傳 `status: true`
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 刪除通知
|
||||
|
||||
`DELETE /api/notifications/{id}` SHALL 永久刪除指定通知。
|
||||
|
||||
#### Scenario: 刪除成功
|
||||
|
||||
- **WHEN** 已登入使用者刪除自己的通知
|
||||
- **THEN** 該通知從資料庫移除，回傳 HTTP 204
|
||||
|
||||
#### Scenario: 非本人通知拒絕刪除
|
||||
|
||||
- **WHEN** 使用者嘗試刪除他人通知
|
||||
- **THEN** 回傳 HTTP 403
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 前端 Bell Icon 未讀計數
|
||||
|
||||
NavBar（MemberNavBar + CoachNavBar）SHALL 顯示通知鈴鐺圖示，未讀數量 > 0 時顯示紅色 Badge。
|
||||
|
||||
#### Scenario: 有未讀通知
|
||||
|
||||
- **WHEN** 使用者登入後 Pinia store polling 回傳 `count > 0`
|
||||
- **THEN** Bell Icon 顯示紅色數字 Badge
|
||||
|
||||
#### Scenario: 無未讀通知
|
||||
|
||||
- **WHEN** `count === 0`
|
||||
- **THEN** Badge 不顯示（隱藏，不佔位）
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 前端通知中心 Drawer
|
||||
|
||||
點擊 Bell Icon SHALL 開啟側邊 Drawer，列出最新 20 筆通知，每筆顯示 title、body（截斷 80 字）、時間（相對時間）、已讀/未讀狀態。
|
||||
|
||||
#### Scenario: 點擊通知項目
|
||||
|
||||
- **WHEN** 使用者點擊通知項目
|
||||
- **THEN** 通知標記為已讀（Optimistic update），並以 `new URL(action_url).pathname` 提取路徑後呼叫 `router.push()`，跳轉至對應頁面
|
||||
|
||||
#### Scenario: 點擊「全部標記已讀」
|
||||
|
||||
- **WHEN** 使用者點擊 Drawer 頂部「全部標為已讀」按鈕
|
||||
- **THEN** 呼叫 `PATCH /api/notifications/read-all`，所有項目變為已讀樣式
|
||||
|
||||
---
|
||||
|
||||
### Requirement: Polling 機制
|
||||
|
||||
前端 Pinia `notificationStore` SHALL 在使用者登入後立即執行第一次 fetch，並依未讀數量動態調整輪詢間隔：未讀 > 0 → 30 秒；未讀 = 0 → 60 秒。間隔切換時 MUST `clearInterval` 後以新間隔重新建立。登出後清除計時器與 Page Visibility 監聽器。
|
||||
|
||||
#### Scenario: 登入後立即 fetch
|
||||
|
||||
- **WHEN** 使用者成功登入（Member 或 Coach）
|
||||
- **THEN** `notificationStore.startPolling()` 立即呼叫一次 `fetchUnreadCount()`，不等待第一個 interval 到期
|
||||
|
||||
#### Scenario: 有未讀時使用 30 秒間隔
|
||||
|
||||
- **WHEN** `fetchUnreadCount()` 回傳 `count > 0`
|
||||
- **THEN** interval 設為 30 秒（若目前為 60 秒則 clearInterval 重啟）
|
||||
|
||||
#### Scenario: 無未讀時降頻至 60 秒
|
||||
|
||||
- **WHEN** `fetchUnreadCount()` 回傳 `count === 0`
|
||||
- **THEN** interval 設為 60 秒（若目前為 30 秒則 clearInterval 重啟）
|
||||
|
||||
#### Scenario: 頁面切換至背景時暫停
|
||||
|
||||
- **WHEN** `document.visibilityState === 'hidden'`（使用者切換 Tab 或最小化視窗）
|
||||
- **THEN** clearInterval 暫停 polling，不發出 API 請求
|
||||
|
||||
#### Scenario: 頁面重新顯示時恢復
|
||||
|
||||
- **WHEN** `document.visibilityState === 'visible'`（使用者回到此 Tab）
|
||||
- **THEN** 立即執行一次 `fetchUnreadCount()`，然後依最新 count 重啟 interval
|
||||
|
||||
#### Scenario: 登出後停止
|
||||
|
||||
- **WHEN** 使用者登出
|
||||
- **THEN** `notificationStore.stopPolling()` 執行 `clearInterval` 並 `removeEventListener('visibilitychange', ...)`，不再發出任何請求
|
||||
Reference in New Issue
Block a user