Jira Issue

Phase 1
Phase 2
Phase 3
Phase 4
Phase 5
Phase 6
Phase 7
Phase 8 (PENDING)
BYNT-1249
BYNT-1254
BYNT-1347
BYNT-1349

Description

[Brief description of changes]

Checklist

• Tests added/updated
• Documentation updated (if needed)
• New strings prepared for translations
• Billing project label added
• API Changes (if applicable)
• Permissions checked
• Endpoint tests added

Additional Notes

GET /admin/api/notifications return a paginated list of all notifications for the current user (descending by created date). Accepts page and per_page query parameters. A sample response looks like below

{
        "items": [],
        "currentPage": int,
        "perPage": int,
        "total": int,
        "hasMore": bool,
        "unreadCount": int
        "hasUnreadUrgentNotifications": bool
}

GET admin/api/notifications/unread/count: return the number of unread notifications for the current user. Will have only one field in JSON response unread_count
POST admin/api/notifications/<int:id>/read: mark the notification with id as read, if it belongs to the current user. Will return a message and the notification on success.

Notification Settings

GET /admin/api/configuration/ configuration response will now contain a dict keyed "NOTIFICATIONS" that is a mix of read-only and configurable items and fields.

"config":{
# ...
"NOTIFICATIONS" : {
    # Security notifications
    "LOGIN_NEW_IP": {
        "in_app_enabled": True,
        "email_enabled": True,
    },
    "PASSWORD_CHANGE": {
        "in_app_enabled": True,
        "email_enabled": True,
    },

in_app_locked and email_locked are read-only fields. Any modifications to these fields will be ignored, as well as any modifications to fields that are marked "locked". That is to say, you can omit the "LOGIN_NEW_IP" when PUTing the configuration, because all of its fields are read-only, it will be ignored by the backend completely and won't be actually persisted in the configuration file.

Some notifications will have a mix of locked and unlocked fields. Modifications made to the unlocked fields will be persisted, whereas any modifications to locked fields will be ignored. Any changes to in_app_locked or email_locked are also ignored.

Any notification configuration sent from the frontend is persisted as is (in config.json), but security-related ones get overridden at runtime when loading the settings.