Update Notifications Feature

[qisforq]

Objective:

Enhance the Notifications section of the Settings page to allow users to manage their notification preferences effectively.

Tasks:

• [x] Research and evaluate different approaches for managing user notification settings, such as using a tagging system similar to Uber (@chef-louis's idea)
• [x] Design a scalable and flexible data model for storing user notification preferences.
• [x] Implement the backend API endpoints to retrieve and update user notification settings.
• [x] Update the Notifications section of the Settings page to display the available notification categories and options (related to #177 )
• [x] Implement toggle switches or checkboxes for each notification category, allowing users to enable or disable specific types of notifications.
• [x] Ensure that the selected notification preferences are saved and persisted correctly when the user updates their settings.
• [x] Test the notification settings functionality to verify that the preferences are accurately stored and applied.
• [x] Consider implementing default notification settings for new users and provide options to customize them during the onboarding process.
• [ ] Evaluate the performance and scalability of the notification settings system, especially for a large number of users and notification categories.

[chef-louis]

Doing some research indicates that having an individual table for users and another for notification preferences, we can then create a many-to-many relationship table between them to house preferences for the various combinations. This seems to be both a performant and scalable approach as we grow the communications channels.

My original tagging idea is comparatively slower as the User table would have an ever growing column with additional tags which would get slower to search through over time. Hence having one many-to-many solution where an entry by default signifies a 'true' boolean for notification preference appears to be the best way to go.

I'll get the relevant tables added

[qisforq]

Nice work on this @chef-louis, the new design approach sounds very intuitive and performant. Looking forward to seeing the tables!

[chef-louis]

• Added lambda function to access notification preferences and render settings appropriately on the front-end
• TODO: add update functionality to POST / update changes in front-end to the backend

[chef-louis]

Functionality of adding / removing notification preferences for users is completed.

TODO for further optimization:

• Refactor User state to leverage Jotai (sanity checking the best approach with Hector)
• Test scalability (There is a bit of a delay when fetching user notification preferences... will discuss with the team on the best path forward)
• Implement default notifications / prompt user on sign-up
• Add a button to quickly unsubcribe from all communications

[chef-louis]

EDIT: Touched base with Paula again and going to explore a modal to engage users directly after sign-up to initialize notification preferences

Deleted previous message for clarity. Still working on a functional modal to enable / disable notifications on first sign-in.