paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 19 Packages Projects Releases Wiki Activity

chore: specify content of a notification

Browse Source 
Signed-off-by: Marek Libra <marek.libra@gmail.com>
This commit is contained in:
Marek Libra
2024-01-25 13:40:34 +01:00
parent 9a8d556661
commit 62ba08930f
1 changed files with 32 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
beps/0001-notifications-system/README.md
+32 -1
View File
@@ -85,12 +85,43 @@ The role of the notifications plugin is to manage the lifecycle of notifications
The notification backend stores notification using the [database service](https://backstage.io/docs/backend-system/core-services/index#database). In particular it needs to store the following information for each notification:
- ID
- Payload
- Title
- Priority
- Origin
- Topic (optional)
- Creation timestamp (generated)
- Receivers
- Read status by user
- Payload
- icon (optional)
- message (optional)
- links (list, optional)
The receivers is **not** a list of users, but rather a filter that describes who should receive the notification. It must be possible to evaluate this filter in a database query, so that we can efficiently fetch all notifications for a given user. The same filter will also be used by the signal backend to determine which users should receive a signal.
The title is mandatory human readable text shortly describing the notifications.
The priority is one of the predefined values to help with presentation of the notifications or their filtering. Values: Critical, High, Normal, Low.
The origin is a string identifying the creator of the notification, i.e. the BE plugin or external system.
The topic is an optional string helping to group notifications of particular context. Its use cases include:
- several notifications emitted by an asynchronous external task can be grouped by a single topic
- a BE plugin can group several related messages to a particular processing, i.e. asynchronous progress monitoring
The timestamp of message creation is auto-generated by the notifications backend at the time of receiving a request to create the notification.
The icon is optional and is meant to improve UX. A string referencing an icon name from MUI icon library of a defined version. If missing, it will be determined from the priority
The message is an optional human readable text providing more details to the user.
The links are an array of title-URL pairs. As an example, they can be used
- by an external system to provide more details related to the notification
- by an external system to request an action within an asynchronous task
- by a BE plugin to provide link to other part of the Backstage UI (i.e. to the Catalog)
The notification backend does not provide any new permissions, since creating notifications can only be done by other backend plugins, while reading notifications can only be done by the authenticated user. It is possible that we want to add a permissions for reading notifications, in particular for admin and impersonation use cases, but that is not part of this proposal or the initial implementation.
The notification frontend plugin provides a UI for viewing notifications, which in the initial implementation can be as simple as needed. The only requirement is that a user is able to view recent notifications and distinguish between read and unread notifications. A notification as marked as read once it has been interacted with. The frontend plugin also subscribes to the notifications signal channel and alerts the user when a new notification is received.