3.1 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