Notification Feature: Push Notifications to alert users

[sleidig]

As a user I should get actively pulled into the app with notifications in order to not miss new developments or required actions.

An overall notification feature should help users stay updated without the need to actively open the app and check data. Instead, both within the app (with some notification indicator) as well as through push notifications, the user should be automatically informed about new details.

---

On a technical level, this feature includes:

• Service to trigger push notifications in a PWA (if needed, including backend and external services)
• UI to show details of notifications within the app and an "unread notifications" indicator
• Configuration logic to allow users to enable/disable different types of notifications for their account individually
• Triggers for specific notifications for certain events:
  • notification when config is changed that affects certain behavior for users (e.g. a different pre-filter for the matching view)
  • notification when a new/changed entity record matches a criteria (e.g. the current user has been added as the "assigned person" on a task record or a new participant with status "signed up through public form" has been added)
• in a future version:
  • notification when a planned date is reached (e.g. on the deadline of a task entity)
  • notification when an app update is available (to highlight new features)
  • emails in addition to push notifications

---

Broken into user stories as implementation steps:

As a user I can

• Receive push notification without opening the app #2662
• View list of notifications in the app #2661
• See unread notifications indicator in the app #2660
• Store and access notifications & mark them "read" #2690
• Configure/Disable certain notifications for a user #2696
• Enhance Notification Settings Logic for User Entity Updates in CouchDB #2723
• Implement Notification Permission and FCM Token Handling #2724
• Receive notification when an entity is updated
  • Trigger rules/filters for "entity update notifications" as an admin #2775
  • ? support placeholders (e.g. "current user") in "entity update notification" rules
• adapt EntityMapper / DatabaseService to sync + access different CouchDBs ("notification_xxx" as well as "app") #2746
• click on Notification entry navigates to the relevant view (e.g. details of the changed entity) #2754
• Notifications: activate/setup initial config #2804

---

Remaining tasks:

Open Issues (Frontend):

• NotificationConfig permission to edit only own needs account-id placeholder in permission/ability system #2847
• "Test Notification" UI alignment & improvements #2849
• Notification: create separate CouchDB to store event entities #2850
• adapt replication-backend for handling multiple databases replication-backend#172
• final final review

Open Issues (Backend):

• filter operator for "in list" ("$elemMatch")
• polish display of system notification message + event_id to frontend
• NotificationEvent structure with context (entityId of affected doc?)
• Notification: init required configs / DBs on backend (user-specific couchdb, permission to edit NotificationConfig, etc.) and add events to separate DB aam-services#70
• tests & review

Later (v1.1)

• pass NotificationEvent._id in the push notification payload and handle this in frontend to navigate to relevant view
• Notifications Config: integrate filter components to define notification criteria #2801

[TheSlimvReal]

As far as I know there are 2 possible options for this currently:

1. Web Push API

You can send a notification message to a centralized server including the ID of the device where this notification should be triggered. This normally needs a backend service that handles the device IDs as well as the notification scheduling (maybe based on time or things happening in the database). The problem is that the central server can decide to drop a notification if e.g. too many notifications have been sent in the recent time.

2. Notification Triggers

From inside the web application notifications can be registered and scheduled. For the notification a so called trigger can be defined that defines when the application should be shown e.g. show a notification on next Monday morning. This has the great benefit that no backend service is required but probably has high limitations in how these triggers can be defined. Might work well for simple time-bound reminders.

[TheSlimvReal]

I seems like the main difference is whether the user should also receive notifications while the app is not running. If this is the case then push notifications should be used. Otherwise, notifications are also an option.

See this post

[Ayush8923]

I’ve documented the current behaviour and the proposed solution in this Document for better clarity and understanding.