3.7 KiB
ADDED Requirements
Requirement: H5/C SHALL surface unread customer notifications
The H5/C client SHALL use GET /api/c/v1/notifications/unread-count for the homepage or notification-entry badge and GET /api/c/v1/notifications for the notification list. It SHALL consume the existing personal-notification contract and SHALL not add a separate API for expiry or exchange reminders.
Scenario: Unread notifications exist
- WHEN the unread-count endpoint returns a positive count
- THEN the homepage or notification entry SHALL display the unread indicator using that count
- AND the notification list entry SHALL remain available
Scenario: No unread notifications exist
- WHEN the unread-count endpoint returns zero
- THEN the client SHALL clear the unread indicator
- AND the notification entry SHALL not show a stale count
Requirement: Expiry and exchange notices SHALL use the shared notification channel
The client SHALL display package-expiry and exchange-related notifications returned for the authenticated customer through the shared notification list or reminder popup. The backend notification data SHALL determine the expiry trigger and severity; the client SHALL not create independent timers that send business notifications.
Scenario: Package reaches a reminder threshold
- WHEN the notification service returns an unread package-expiry notice for the 15-day, 7-day, or 3-day threshold
- THEN the client SHALL display it through the existing H5/C notification entry or popup
- AND the client SHALL use the returned expiry level for presentation
Scenario: Critical expiry notice has highest priority
- WHEN unread expiry notices include a notice for 0 to 3 remaining days
- THEN the client SHALL give that notice the highest reminder priority
- AND the client SHALL not downgrade it based on a client-side date calculation
Scenario: Exchange notification is returned
- WHEN an exchange-related unread notice is returned after an exchange is created
- THEN the notification entry/list SHALL display the notice
- AND the client SHALL not call a separate marketing, ERP, or salesperson notification endpoint
Requirement: Viewing a notification SHALL support marking it read
When the user views or activates a notification, the client SHALL call PUT /api/c/v1/notifications/{id}/read for that notification and reconcile the local unread count after a successful response. Repeated read actions SHALL remain safe according to the existing notification API contract.
Scenario: User reads an unread notice
- WHEN the user opens or advances to an unread expiry or exchange notification
- THEN the client SHALL mark that notification read through the existing endpoint
- AND the badge/list state SHALL reflect the read result
Scenario: Notification read request fails
- WHEN marking a notification read fails
- THEN the client SHALL retain the unread state or refresh it from the backend
- AND the failure SHALL not prevent the user from viewing other asset or notification content
Requirement: Multi-notification popup SHALL communicate horizontal navigation
When the homepage notification popup contains more than one notification, the client SHALL make the horizontal swipe interaction visible to the user and SHALL retain the current-position indicator.
Scenario: User opens multiple unread notifications
- WHEN the homepage popup contains two or more notifications
- THEN the popup SHALL display an explicit
左右滑动切换通知hint - AND the user SHALL be able to move between notifications by swiping horizontally
- AND the popup SHALL display the current notification position