67 lines
3.7 KiB
Markdown
67 lines
3.7 KiB
Markdown
## 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
|