Feat/notifications

[alexanderleegs]

Problem

This PR adds a partial implementation of the notifications feature, as described in https://www.notion.so/opengov/Comments-Notifications-4332401f397c487e9a6e3bf641b23814#9557a87f679e458ba0b1cfc6c3d11eca.

It adds a baseline for notification creation, retrieval, and updating, but actual notification creation will be tackled in a future PR, after review requests have been completed. It also adds a notifications table to our database, and modifies our existing site members table to add an id field for easier reference by related tables. To be reviewed in conjunction with PR isomerpages/isomercms-frontend#1092 on the isomercms-frontend repo.

Key changes

• Added new P1 notification endpoints (getRecentNotifications, getAllNotifications, markNotificationsAsRead)
• Added NotificationService to handle above endpoints, as well as generic create endpoint to support notification creation in future
• Added Notification database table
• Modified existing SiteMember database table to add id column and swap primary key

Future work

• Notification creation as side effect of actions

Testing

As notifications cannot be created currently, we have to manually populate the notifications table. To do so:

1. Run db:migrate
2. Add the following notifications to the notifications table

1	{your_site_member_id}	{your_site_id}	{your_user_id}	user created a review request.	google.com	username	sent_request	NULL	2	2022-09-30 08:57:20.689+00	2022-10-02 06:27:36.233+00
2	{your_site_member_id}	{your_site_id}	{your_user_id}	different message here to read	google.com	diffuser	sent_request	2022-10-03 04:42:01.784979+00	2	2022-09-30 08:57:20.689+00	2022-10-02 06:27:36.233+00
3	{your_site_member_id}	{your_site_id}	{your_user_id}	third different message here	google.com   undefined     	sent_request	2022-10-03 03:36:40.597+00	2	2022-09-30 08:57:20.689+00	2022-10-03 03:36:40.597+00

3. The notification which has no first_read_time should show up as an unread notification on the frontend, and be marked as read once viewed. The notification which has no username defined should have a generic bell icon show up instead of the user's initials (icon to be changed later depending on notification type)

[dcshzj]

Sorry one more point, should this priority be descending instead? Meaning that a higher priority should be shown first.

Also, should we also include the notification creation time and sort by descending order? So the sorting order is something like this:

1. Notifications that the user has not seen before will be at the top.
2. Notifications that are more recent are shown first, if the user has not seen it before or multiple notifications have the same first read time.
3. If all else equal, then show notifications with a higher priority first.

[alexanderleegs]

I've add the time the notification is created to the sorting criteria in dc77d8d! But 2 and 3 are swapped - when a user first logs in, they should see in order:

1. Unseen notifications
2. High priority notifications
3. Notifications created more recently

The reason for this is that upon login, any high priority unread notifications should always be at the top of the list, and since reminder notifications are going to only be created once a day, it's very likely for a lower priority notification to be created afterwards.

I've also left the priority direction as is for now - I put it as ascending because I was imagining lower numbers to mean higher priority (so P1 > P2), but I'm open to changing this if it's not intuitive, since the higher priority reminder notifications will only be added later!

[alexanderleegs]

As discussed offline, both conditions actually need to be fulfilled -

• For unread notifications, priority should be the determining factor
• For read notifications, they can be sorted by creation time.

This behaviour has been fixed in 7b4e423!

[dcshzj]

LGTM! Just need to add comments to explain the sorting order + lower priority number == higher priority notification