RevenuePilot CRM Documentation
Ctrl+K
v1.0.0 Changelog
Docs / Notification Module

Notification Module

The notification module gives the application a shared in-app inbox: bell dropdown access from the navbar, a full notification center page, structured detail pages, read and unread actions, and permission-aware visibility in the sidebar and navbar.

What This Module Includes
  • Navbar bell icon with unread badge.
  • Recent notification dropdown with unread highlighting.
  • Notification center listing with live filters and actions.
  • Activity log listing for important admin-facing events.
  • Dedicated notification detail page with payload breakdown.
  • Dedicated activity log detail page with audit context and trace data.
  • Read, unread, and mark-all-read actions when allowed.
Technical Shape
  • Routes live in routes/notification.php.
  • Controllers live in app/Http/Controllers/Admin/Notifications.
  • Business logic lives in app/Services/Notification/NotificationService.php.
  • Query logic lives in app/Repositories/Notification/NotificationRepository.php.
  • UI files live in resources/views/admin/notification and public/assets/js/pages/admin/notifications.

Where Users See Notifications

Navbar Bell
  • Visible only to users who have view notifications.
  • Unread badge updates from the shared dropdown payload.
  • Dropdown items open the internal notification detail page first.
  • Mass read is shown only when the user also has manage notifications.
Sidebar Placement
  • The sidebar places Notifications in the Main section under Dashboard.
  • When the user has both inbox and activity-log access, Notifications opens as a dropdown with Inbox and Activity Logs.
  • This keeps both live alerts and audit review close to daily admin activity.
  • The sidebar entry uses the same active-state styling as the rest of the app shell.

Permissions

Notification Permission Map
  • view notifications: view the bell dropdown, unread badge, notification center listing, and notification detail pages.
  • manage notifications: mark notifications as read or unread and use the mark-all-read actions in the page and dropdown.
  • view activity logs: access activity log listing and activity log detail pages for admin-facing audit events.
Default roles: Admin, Manager, and Employee receive both notification permissions from the current seed configuration, while custom roles can split view and manage access if needed.

UI Standards Followed

Shared UI Rules Used
  • The listing uses the shared table design and shared table filters flow.
  • The notification center uses the shared page header component.
  • Primary actions use the shared button component.
  • Field controls use shared input and search select components.
  • Dropdown and detail styling extend the page CSS only, not shared component CSS.

Detail Screens

Both notifications and activity logs open into internal detail pages. These screens use the shared page header for the main page title, then switch into table-style overview and summary panels instead of inventing a separate detail layout system.

  • Overview panel: identifiers, source, actor, subject, and status.
  • Summary panel: main human-facing message plus compact detail rows or audit context tags.
  • Structured details panel: payload fields like patient ID, document name, IP, device, or custom metadata.
  • Trace panel: event key, module or source, timestamps, and read or severity state.

Notification Sources

Current Source Buckets
  • Security & Auth: password, OTP, two-factor, and security events.
  • Patients: patient activity such as visits, documents, or profile actions.
  • System: fallback bucket for uncategorized notification payloads.

Activity Logs

What Gets Logged
  • important patient lifecycle events such as create, update, archive, restore, encounters, and documents.
  • important security events such as OTP generation, account lock, password reset actions, and TOTP changes.
  • events are stored in activity_logs with module, event key, title, description, severity, related subject, actor, and payload properties.

Request And Feedback Flow

  1. User clicks a notification action.
  2. A shared Swal confirmation appears when the action needs approval.
  3. A shared loading Swal appears while the request is in progress.
  4. The backend returns JSON for mutating actions.
  5. A shared Toastr success or error message is shown.
Shared alert stack: the notification module uses the same shared alerts.js and toastr-dark.css flow as settings, roles, auth, and patient actions.
Loader split: table filters use the shared table-loader.js, form and AJAX actions use Swal loading states, and full-page navigation uses the shared page loader. These three loading systems are intentionally separated.

Route Map

GET    /notifications
GET    /notifications/listing/data
GET    /notifications/dropdown
GET    /notifications/activity-logs
GET    /notifications/activity-logs/listing/data
GET    /notifications/activity-logs/{activityLog}
GET    /notifications/{notification}
POST   /notifications/read-all
POST   /notifications/{notification}/read
POST   /notifications/{notification}/unread

Service And Repository Responsibilities

Repository
  • Owns the current user notification query.
  • Handles filtering, pagination, and unread counts.
  • Updates read and unread state for the database notification rows.
Service
  • Transforms database payloads into table rows, dropdown items, and detail views.
  • Builds source labels, icons, timestamps, detail lines, and structured facts.
  • Controls the internal detail page links and related module jump links.

Testing And Validation

Current Coverage
  • notification listing rendering and shared filter behavior.
  • navbar bell dropdown rendering and unread count updates.
  • detail page rendering and automatic read state updates.
  • read, unread, and mark-all-read JSON actions.
  • activity log listing and activity log detail rendering.
  • live activity-log recording from patient and security flows.
  • permission gating for no-access and view-only users.
php artisan test --filter=NotificationModuleTest
php artisan test --filter=ActivityLogModuleTest
php artisan route:list --name=notifications
php artisan view:cache

Extension Points

app/Http/Controllers/Admin/Notifications
app/Repositories/Notification/NotificationRepository.php
app/Services/Notification/NotificationService.php
resources/views/admin/notification
public/assets/js/pages/admin/notifications
public/assets/css/pages/notifications
routes/notification.php
Operational note: mutating notification actions are expected to return JSON. If a custom change starts returning redirects or HTML for read or unread actions, the shared Swal plus Toastr flow will break.
Previous: Roles & Permissions