Appearance
Notifications & Alerts
The system implements a multi-channel notification engine to keep dispatchers and drivers synchronized. This includes targeted user notifications, system-wide announcements, and mobile push alerts.
🛠️ Technical Tables
notifications (User Specific)
Stores individual alerts for a specific user.
type: Enum defining the alert category:assignment: New trip or resource assignment.reminder: Upcoming schedule alerts.alert: High-priority operational issues.
isRead: Boolean flag to track user acknowledgement.referenceType&referenceId: Polymorphic links to the source entity (e.g., links directly to atriporcar_handover).
push_tokens (Mobile Delivery)
Maps users to their physical mobile devices for Expo Push Notifications.
token: The unique Expo push token.platform:iosorandroid.deviceId: Unique hardware identifier to prevent duplicate tokens.
announcements (Broadcasting)
System-wide messages filtered by user roles.
targetRole: Filters who sees the message (driver,transport_admin,all, etc.).expiresAt: Automatic cleanup/expiration of the announcement.
📡 Delivery Channels
1. In-App Notifications
Both the Admin Dashboard and Driver App fetch unread alerts from the /notifications API endpoint. The UI provides a "badge" count and a list view for these alerts.
2. Push Notifications
When a critical event occurs (like a new trip assignment), the Backend API triggers a push notification via the stored push_tokens. These appear as system-level alerts on the driver's smartphone.
3. Real-Time Updates (WebSockets)
The ws module pushes immediate updates to active web and mobile sessions. This is used for "silent" data refreshes (e.g., updating a trip status on a dispatcher's screen without a page reload).
🔄 Core Notification Logic
- Triggers: Events are triggered by status changes in the
tripsorcar_handoverstables. - Lifecycle: A notification is created -> Push is sent -> User clicks/reads in-app ->
isReadis patched totrue.