
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview
As part of this issue, we will implement support for displaying a red dot on the user profile and a notifications option to indicate when the user has received a new notification. New notifications will only be flagged when:
- A user creates a new Submission -> A notification is flagged to the channel editors, other than the one who made the submission.
- An admin resolves a Submission -> A notification is flagged to all channel editors.
Technical details
New field in User model
- To persist the number of notifications that the user has not read, we will add a new
unread_notifications_count to the User model and to the UserViewSet.
- When a submission is created, we should increment this field by 1 for all channel editors.
- When a submission is resolved, we should increment this field by 1 for all channel editors.
- We should create a new endpoint in the
UserViewSet to mark X number of notifications as read. This endpoint will decrement the given number from the unread_notifications_count field.
- The reason why it is better to decrement rather than just set it to 0 is to prevent concurrency errors in case a new notification had been published while the user was viewing the notifications page.
Change events
- For every change to this field, we should create a new
applied=True change event to the session table, so that, when the changes are synced to the frontend, this number is updated.
- For this, we will need to add a new
SESSION table in the ALL_TABLES set
- Since the pk for this table in the frontend is CURRENT_USER, we will need to use the "CURRENT_USER" string as pk for the change.
UPDATE_SESSION_FROM_INDEXEDDB(state, { CURRENT_USER, ...mods }) {
if (CURRENT_USER === 'CURRENT_USER') {
state.currentUser = { ...applyMods(state.currentUser, mods) };
}
},
Red dot display
- To return this new
unread_notifications_count field and make it available in the frontend, we should add this field to the user_fields tuple.
- We should then update the AppBar component to reflect the red dot on the user profile if
user.unread_notifications_count > 0.
Notifications page updates
- On the Notifications page, a new KTabs component should be added to differentiate "UNREAD" vs "ALL NOTIFICATIONS" (Figma specs here).
- To load the Community Library Submission updates on the unread tab, we should look at how many
unread_notifications_count exist, and load and display just that number of updates.
- When the user clicks on the "clear all" button, a request should be made to the previously described endpoint to decrement the number of unread notifications that were loaded when the page was mounted.
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Overview
As part of this issue, we will implement support for displaying a red dot on the user profile and a notifications option to indicate when the user has received a new notification. New notifications will only be flagged when:
Technical details
New field in User model
unread_notifications_countto the User model and to the UserViewSet.UserViewSetto mark X number of notifications as read. This endpoint will decrement the given number from theunread_notifications_countfield.Change events
applied=Truechange event to thesessiontable, so that, when the changes are synced to the frontend, this number is updated.SESSIONtable in the ALL_TABLES setidis the pk field, but it's not, so we should update this method to be something like this, to reflect the correct pk field:Red dot display
unread_notifications_countfield and make it available in the frontend, we should add this field to the user_fields tuple.user.unread_notifications_count > 0.Notifications page updates
unread_notifications_countexist, and load and display just that number of updates.