Overview

The notification module delivers real-time in-app messages to users when relevant platform events occur. Notifications are scoped to the account owner — sub-users see the owner's notifications rather than maintaining a separate inbox. A second model, Announcement, carries platform-wide messages from Ananas GDS administrators.

Notification Model

FieldDescription
user_idFK to the user who receives the notification (always the owner for sub-user accounts).
notification_typeCategory of notification (see types table below).
messageShort human-readable description, up to 255 characters.
is_readWhether the user has read this notification. Default false.
extra_idOptional integer linking to a related object (e.g. invoice ID, contract ID).
linkOptional URL the notification links to within the app.
created_atTimestamp when the notification was created.
created_byThe user or system actor that triggered the notification.

Notification Types

TypeUse Case
noticeGeneral platform notices and informational messages.
messageDirect messages from another account or the platform.
applicationPartner connection requests or application-level events.
requestActions requiring user approval — e.g. a TO requesting data access.
updateData change alerts — fact sheet updated, stop sale changed.
securityLogin alerts, new session from an unrecognised IP, session limit reached.

Sub-User Scoping

When a sub-user is authenticated, Notification.get_user_notifications(user) checks user.manager — if set, it fetches notifications addressed to the manager (owner). This means sub-users share the owner's notification inbox without the platform needing to duplicate records.

Notification preferences

Per-user notification toggles are stored in Preferences (settings app) — see the Settings module for full details. Toggles include partnership requests, fact sheet changes, fact sheet downloads, and fact reviews.

Platform Announcements

The Announcement model carries broadcasts created by Ananas GDS administrators. Announcements appear in a dedicated section of the dashboard and are not per-user — every user sees all active announcements. Categories are announce (new feature or important notice) and Update (platform release notes).

API Endpoints

MethodPathDescription
GET/api/notification/notification/List all notifications for the authenticated user (unread first, ordered by created_at desc).
GET/api/notification/notification/count/Returns the unread notification count. Used by the top-nav badge.
PATCH/api/notification/notification/edit/Mark a specific notification as read. Body: {id}.
POST/api/notification/notification/mark-all-read/Mark all notifications for the user as read.
DELETE/api/notification/notification/delete/Dismiss (delete) one or more notifications. Body: {ids: [...]}.
GET/api/notification/announce-app/List current platform-wide announcements.

How Notifications Are Created

Notifications are created programmatically within backend views using the Notification model directly — there is no separate notification service layer. Common trigger points include:

  • Contract status changes (partner accepts, rejects, or proposes amendment)
  • Fact sheet review status changes (approved, declined)
  • Invoice lifecycle transitions (sent, viewed, disputed, paid)
  • New login from an unrecognised IP address
  • Session limit reached
  • New partner connection request received

Polling vs. push

The frontend polls /api/notification/notification/count/ on a short interval to update the badge counter. Full notification list is fetched on demand when the user opens the notification panel.