a6bc9666e1
- Introduced MeStatus module to aggregate customer status, integrating dashboard summary, payment methods, internet eligibility, and residence card verification. - Updated dashboard hooks to utilize MeStatus for improved data fetching and error handling. - Enhanced notification handling across various modules, including cancellation notifications for internet and SIM services, ensuring timely user alerts. - Refactored related schemas and services to support new dashboard tasks and notification types, improving overall user engagement and experience.
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# Dashboard & Notifications
|
||
|
||
This guide explains how the **customer dashboard** stays consistent and how **in-app notifications** are generated.
|
||
|
||
## Dashboard “single read model” (`/api/me/status`)
|
||
|
||
To keep business logic out of the frontend, the Portal uses a single BFF endpoint:
|
||
|
||
- **Endpoint**: `GET /api/me/status`
|
||
- **Purpose**: Return a consistent snapshot of the customer’s current state (summary + tasks + gating signals).
|
||
- **Domain type**: `@customer-portal/domain/dashboard` → `meStatusSchema`
|
||
|
||
The response includes:
|
||
|
||
- **`summary`**: Same shape as `GET /api/me/summary` (stats, next invoice, activity).
|
||
- **`internetEligibility`**: Internet eligibility status/details for the logged-in customer.
|
||
- **`residenceCardVerification`**: Residence card verification status/details.
|
||
- **`paymentMethods.totalCount`**: Count of stored payment methods (or `null` if unavailable).
|
||
- **`tasks[]`**: A prioritized list of dashboard tasks (invoice due, add payment method, order in progress, eligibility pending, IDV rejected, onboarding).
|
||
|
||
Portal UI maps task `type` → icon locally; everything else (priority, copy, links) is computed server-side.
|
||
|
||
## In-app notifications
|
||
|
||
In-app notifications are stored in Postgres and fetched via the Notifications API. Notifications use domain templates in:
|
||
|
||
- `packages/domain/notifications/schema.ts`
|
||
|
||
### Where notifications are created
|
||
|
||
- **Eligibility / Verification**:
|
||
- Triggered from Salesforce events (Account fields change).
|
||
- Created by the Salesforce events handlers.
|
||
|
||
- **Orders**:
|
||
- **Approved / Activated / Failed** notifications are created during the fulfillment workflow:
|
||
- `apps/bff/src/modules/orders/services/order-fulfillment-orchestrator.service.ts`
|
||
- The notification `sourceId` uses the Salesforce Order Id to prevent duplicates during retries.
|
||
|
||
- **Cancellations**:
|
||
- A “Cancellation scheduled” notification is created when the cancellation request is submitted:
|
||
- Internet: `apps/bff/src/modules/subscriptions/internet-management/services/internet-cancellation.service.ts`
|
||
- SIM: `apps/bff/src/modules/subscriptions/sim-management/services/sim-cancellation.service.ts`
|
||
|
||
- **Invoice due**:
|
||
- Created opportunistically when the dashboard status is requested (`GET /api/me/status`) if an invoice is due within 7 days (or overdue).
|
||
|
||
### Dedupe behavior
|
||
|
||
Notifications dedupe is enforced in:
|
||
|
||
- `apps/bff/src/modules/notifications/notifications.service.ts`
|
||
|
||
Rules:
|
||
|
||
- For most types: dedupe is **type + sourceId within 1 hour**.
|
||
- For “reminder-style” types (invoice due, payment method expiring, system announcement): dedupe is **type + sourceId within 24 hours**.
|
||
|
||
### Action URLs
|
||
|
||
Notification templates use **authenticated Portal routes** (e.g. `/account/orders`, `/account/services`, `/account/billing/*`) so clicks always land in the correct shell.
|