Notification Model and Endpoints #286

zorazrr · 2022-02-11T05:30:49Z

Notification Model and Endpoints

Create notification model and corresponding endpoints

Closes #284

Changes

Create notification model

id
message
recipient
source
viewed
date

Create endpoints for

Get a list of all notifications
Get a list of notifications by user
Update a notification by id
Delete a notification by id

Add notification preference enum in creator model

Requests / Responses

Request
GET /api/notifications/ Returns a list of notifications
GET /api/notifications/[user-id]/notifications/ Returns a list of notifications associated with a certain user
POST /[notification-id]/update/ Updates a notification
DELETE /[notificaiton-id]/delete/ Deletes a notification

NdibeRaymond · 2022-02-13T18:16:10Z

see #287 (comment)

NdibeRaymond · 2022-02-21T04:24:13Z

zubhub_backend/zubhub/notifications/models.py

+    recipient = models.ForeignKey(
+        Creator, on_delete=models.CASCADE, null=True, related_name="notification_recipient", blank=True)
+    source = models.ForeignKey(
+        Creator, on_delete=models.CASCADE, null=True, related_name="notification_source", blank=True)


I think source pointing to the Creator model is a little bit undesirable. We need to think about the bigger picture. Notification is the place where all the information the Zubhub APP wants to communicate to the user lives. It can be a registration welcome message, email verification reminder/message (or phone verification reminder) or a whole bunch of things that are not related to another user.
I think source should be removed entirely. All notifications are messages from Zubhub app. Any information about the reason for the notification will be included in the notification message itself. We can parse this message if we need to do fancy stuffs (like link to the profile of the user that liked your project, etc)

I understand what you're saying but we were more concerned about getting the profile pic and username for certain notification messages. For example, if a notification stated "<user_name> started following you" we could reference that user in source and have "started following you" in the message. This would allow us to have the profile picture and username in the notification message and also link to their profile when clicked on. Do you know how we might be able to get something like the user's profile picture without using a source field?

Simply adding the username of the user that followed another user in the notification message is enough to get all the extra interactions we need. The profile picture is auto-generated based on the username, so having the username is enough to get the profile picture. as for linking to the profile, there is a function in the frontend that parses strings and can detect the presence of sub-strings with a particular format (@username). With this we can format the incoming notification string and replace @username with <a href="link to profile">username</a>.
Of course if a user changes their username, then the profile can no longer be found. But this is not much of a problem since a username is not something that changes often and if it does, we can simply report that the user profile is not found. The bigger issue is restricting the notification model to just user-to-user notifications.

I will also think more about this to see if there is a better way. But I'm sure source pointing to Creator model is not a good design.

At some point in the future, it seems logical to allow users to upload their own profile pics and in that case, this wouldn't work. Some of the concerns you've outlined with your design are also valid so we should try to find a better design that minimizes bugs and allows for feature additions in the future.

Would it be ok to make the source field NULL for non-user-generated notifications and also add a notification_type field to the model. This would be an enum that could hold values such as follow, like, email_verification so that the frontend would know how to appropriately display the notification. Depending on whether the notification_type is email_verification or something different, the frontend could choose to show an icon that appropriately reflects it. There don't seem to be too many notification use cases so this enum wouldn't end up being too long.

NdibeRaymond · 2022-02-21T04:26:48Z

zubhub_backend/zubhub/creators/models.py

@@ -66,6 +76,9 @@ class Creator(AbstractUser):
    role = models.PositiveSmallIntegerField(
        choices=ROLE_CHOICES, blank=True, null=True, default=CREATOR)
    search_vector = SearchVectorField(null=True)
+    contact = models.PositiveSmallIntegerField(


contact should be inside the Settings model since it's something that is not directly related to user but is more like a settings stuff.

NdibeRaymond · 2022-02-21T04:32:21Z

zubhub_backend/zubhub/notifications/urls.py

+app_name = "notifications"
+
+urlpatterns = [
+    path('', NoticationListAPIView.as_view(), name='list_notifications'),


What will this endpoint be used for? I don't see us ever needing to fetch all notifications in the database.

NdibeRaymond · 2022-02-21T04:35:29Z

zubhub_backend/zubhub/notifications/urls.py

+         name='update_notification'),
+    path('<uuid:pk>/delete/', DeleteNotificationAPIView.as_view(),
+         name='delete_notification'),
+    path('<uuid:pk>/notifications/',


notification is a personal stuff and a user should only be able to fetch their own notifications. for a user to be able to fetch their notifications, they need to be logged in. If a user is logged in, we know who the user is and we can get their username and id from requests.user. uuid:pk is redundant here since we already have the user's information in the request since they are logged in.

NdibeRaymond · 2022-02-21T04:36:16Z

zubhub_backend/zubhub/notifications/views.py

+class NoticationListAPIView(ListAPIView):
+    queryset = Notification.objects.all()
+    serializer_class = NotificationSerializer
+    permission_classes = [AllowAny]


All of NotificationListAPIView should be removed.

NdibeRaymond · 2022-02-21T04:53:57Z

zubhub_backend/zubhub/notifications/views.py

+    permission_classes = [AllowAny]
+
+
+class UpdateNotificationAPIView(UpdateAPIView):


Rename to MarkNotificationAsViewedAPIView or something similar

add throttling

NdibeRaymond · 2022-02-21T04:56:21Z

zubhub_backend/zubhub/notifications/views.py

+    queryset = Notification.objects.all()
+    serializer_class = NotificationSerializer
+
+    def delete(self, request, *args, **kwargs):


remove all of delete method too. Django can handle single actions like deletion without much overriding.

add throttling

zubhub_backend/zubhub/notifications/views.py

NdibeRaymond · 2022-02-21T05:10:11Z

zubhub_backend/zubhub/notifications/utils.py

@@ -0,0 +1,11 @@
+def notification_changed(obj, instance):


maybe delete this function? it doesn't serve any purpose now. see other reviews to know why.

NdibeRaymond · 2022-02-21T05:17:52Z

zubhub_backend/zubhub/notifications/serializers.py

+        model = Notification
+        fields = (
+            'id', 'message', 'recipient', 'source', 'viewed', 'date'
+        )


read_only_fields = ["id", "message", "recipient", "date"]
once a notification has been created, it shouldn't be that easy to change those fields assigned to read_only_fields.
It should only be possible to change the viewed field in notifications from False to True (not from True to False).
As for source field, see other reviews as to why I removed it.

you should overide update method here to check if a notification is viewed or not and if not viewed, set as viewed.

NdibeRaymond · 2022-02-21T05:33:11Z

It feels like the whole notification stuff should be added into the creator app directly because it's too lean and depends a lot on the Creator model to be a standalone app on it's own. the Notification model can be added into creators/models.py, same with serializer and views. We shouldn't have a standalone notification app.

NdibeRaymond · 2022-02-26T04:36:03Z

zubhub_backend/zubhub/APIS/urls.py

+    path('upload_file/', UploadFileAPIView, name="upload_file"),
+    path('delete_file/', DeleteFileAPIView, name="delete_file"),
+    path('upload_file_to_local/', UploadFileToLocalAPIView,
+=======


hello @zorazrr , you should fix this merge conflict when you can. for the purpose of having a consistent style for creating url endpoints, we changed all use of underscores to "-" e.g. upload_file was changed to upload-file.

NdibeRaymond · 2022-02-26T04:39:53Z

zubhub_backend/zubhub/creators/models.py

    creator = models.OneToOneField(
        Creator, on_delete=models.CASCADE, primary_key=True)
    subscribe = models.BooleanField(blank=True, default=False)
+    contact = models.PositiveSmallIntegerField(


Thanks for fixing this @zorazrr, this is definitely better. Another suggestion, right now we send all notifications to both email and phone. With this, we can have a logic every time we send notifications that detect the user's preferred notification channels and only notify then through that channel (you can also create a task for this)

In PR #306, @zorazrr is working on creating a helper function that will call one of the task functions (send_text, send_whatsapp, send_email) based on a user's channel preferences so that other functions just have to call this helper function and not worry about that detail. This function will also add the notification to the notifications model appropriately. My plan was to add this function in a utils.py file in the notifications folder. Do you feel that would be the right place for it?

NdibeRaymond · 2022-02-26T04:42:08Z

zubhub_backend/zubhub/notifications/admin.py

+# Register your models here.
+from .models import Notification
+
+admin.site.register(Notification)


I think we can improve this a bit. Right now in the admin site this will probably just be displaying the default model str method return value. That a difficult ux for admins to handle since they'll probably have no idea about the context of the notification (to who, why, from where, etc). That improvement can be made later.

NdibeRaymond · 2022-02-26T04:46:44Z

zubhub_backend/zubhub/notifications/urls.py

+
+urlpatterns = [
+    path('<uuid:pk>/update/', MarkNotificationAsViewedAPIView.as_view(),
+         name='update_notification'),


when you can @zorazrr spend sometime converting all your underscore based urls to use "-" instead. I admit it was my fault for creating a mixed pattern before. I fixed the mixed pattern by refactoring all urls to not use underscores anymore. You can help me keep to this pattern by changing these too.

…turedstudio/zubhub into gz-zz/notification-model

* initial commit * fix namings * Add update and delete requests * Add boilerplate stuff * finish all endpoints * Add source and preferred contact * modifications to notification endpoints * fix notification list view * hyphens * address merge conflict * Update start Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: Grace Zhang <[email protected]> Co-authored-by: Aditya Jain <[email protected]> Co-authored-by: Zora Zhang <[email protected]>

* Create notifications folder in zubhub_backend/zubhub, begin implementing test functions * Move send_whatsapp function to adapters.py, create task in tasks.py, create send-notification path for testing, test get method in views * Create notifications folder in zubhub_backend/zubhub, begin implementing test functions * Move send_whatsapp function to adapters.py, create task in tasks.py, create send-notification path for testing, test get method in views * Use whatsapp phone in adapter * Fix whatsapp message sending * Fix bug in send_whatsapp function in adapters.py * Fix settings name * Notification Model and Endpoints (#286) * initial commit * fix namings * Add update and delete requests * Add boilerplate stuff * finish all endpoints * Add source and preferred contact * modifications to notification endpoints * fix notification list view * hyphens * address merge conflict * Update start Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: Grace Zhang <[email protected]> Co-authored-by: Aditya Jain <[email protected]> Co-authored-by: Zora Zhang <[email protected]> * Add notification button components (#302) * Add notification button components * Fix popper positioning * Add popper arrow and inner content * Give dropdown box shadow * Add mobile view * Fix box shadow on arrow for dropdown panel * Fix coloring of unread notifications text * Add push notification util function and use CreatorSerializer (#316) * Add push notification util function and use CreatorSerializer for notification serializer * Add notification type field to notification model * Add type to notification serializer and add migration * Remove references to message property of notification * Add viewed to notification serializer * Use creator minimal serializer * Add new link property to notification model * Notification Helper Function (#306) * initial setup * add setting * fix the way to get setting * commit * finished and tested function * add original code back in * modify function to send mass text/email * Add channel verification Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: Aditya Jain <[email protected]> * Fix migrations * Add several functions and maps for notifications logic (#324) * Add several functions and maps for notifications logic, not working * Finish notification sending function * Remove redundant check for valid notification channel for notification type * Send notifications when notification events occur * Recommend unused function * Add throttle classes back * Fix file extensions * Fix notification template prefix * Add message field to notification model to support notifications that mention project names * Properly create migrations and use char field * Use name instead of label for django integer choice class * Change notification link attribute to be a char field * Fix email templates for notifications * Notifications panel loading notifications complete (#341) * Notifications panel loading notifications complete * Use artifical loading for pages after 1 * Change padding * Add comment for recent notification threshold * Remove console log * Format * Remove unncessary space * Reset scroll on notification tab change * Add notification grouping code (#351) * Add notification grouping code * Use set to determine valid grouped notification types * Actually make the grouping work * Persist context for pushing notifications * Remove prints * Fix django db warning' * Return notification in all branch paths * No need to return notification * Notification Component for Notification Panel (#311) * Outline for Notification components and stylings * Testing notification * Complete majority of stylings for notification component, add dummy component and props to PageWrapper.jsx * Complete stylings for notification component, fix hovers! * Make small style changes to notification component * Begin connecting to backend using realistic parameters, not clean or very functional yet * Begin adapting notification panel to hold notification components * Finish stylings for notification component and message rendering * Finish up API methods to updated viewed notification, add token constant to component * Add logic for rendering notification timestamp, redirect link, and notification message * Clean up and reduce code, remove redunant or unused sections * Move renderTimeAgo and getNotification to new NotificationScripts.js file, simplify logic in scripts, remove viewComment from userActions.js, call API.viewNotification directly in component * Add proper date formatting using dFormatter, string truncation for notification message * Add double image design to nofications, add project titles to views, fix small format issue in comment template * Finish up issue, update notification templates for consitency, fix bug in project details useEffect * Update clapped web_many message to not include strong tags * Update web_many message templates to include project name * Fix url * Minor fixes, add mobile width dependency, update getMessage() to get consistent character limits, remove mock data from PageWrapper Co-authored-by: Aditya Jain <[email protected]> * Notification feature fix (#429) * Fix most notification feature bugs * Fix app bar on top of other elements * Fix panel zindex * Fix panel loading * Fix comment notif Co-authored-by: Aditya Jain <[email protected]> * Add quotes to template * linearize migrations * Fix import * Add project to template * Styling fixes * Delete .gitignore Co-authored-by: saxytony <[email protected]> Co-authored-by: AndrewLester <[email protected]> Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: Grace Zhang <[email protected]> Co-authored-by: Zora Zhang <[email protected]> Co-authored-by: saxytony <[email protected]>

initial commit

5b8a65f

Zora Zhang and others added 5 commits February 14, 2022 20:59

fix namings

85a564d

Add update and delete requests

081e7cd

Add boilerplate stuff

4aba119

finish all endpoints

ec348aa

Add source and preferred contact

45b565d

zorazrr marked this pull request as ready for review February 19, 2022 02:15

zorazrr requested review from NdibeRaymond, tuxology and ajain1921 as code owners February 19, 2022 02:15

NdibeRaymond requested changes Feb 21, 2022

View reviewed changes

Zora Zhang and others added 3 commits February 21, 2022 22:13

modifications to notification endpoints

29d3fd8

fix notification list view

9b9ab6c

Address merge conflicts

2c2a7a4

NdibeRaymond reviewed Feb 26, 2022

View reviewed changes

zorazrr and others added 4 commits February 28, 2022 16:10

hyphens

5f71686

Merge branch 'gz-zz/notification-model' of https://github.com/unstruc…

e450def

…turedstudio/zubhub into gz-zz/notification-model

address merge conflict

8911136

Update start

52502cb

ajain1921 approved these changes Mar 1, 2022

View reviewed changes

ajain1921 changed the base branch from master to notification_feature March 1, 2022 03:12

ajain1921 merged commit 16119fd into notification_feature Mar 1, 2022

tuxology deleted the gz-zz/notification-model branch September 29, 2023 00:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Notification Model and Endpoints #286

Notification Model and Endpoints #286

zorazrr commented Feb 11, 2022 •

edited

Loading

NdibeRaymond commented Feb 13, 2022

NdibeRaymond Feb 21, 2022

ajain1921 Feb 21, 2022 •

edited

Loading

NdibeRaymond Feb 21, 2022 •

edited

Loading

NdibeRaymond Feb 21, 2022

ajain1921 Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond Feb 21, 2022

NdibeRaymond commented Feb 21, 2022 •

edited

Loading

NdibeRaymond Feb 26, 2022

NdibeRaymond Feb 26, 2022

ajain1921 Feb 26, 2022

NdibeRaymond Feb 26, 2022

NdibeRaymond Feb 26, 2022

		permission_classes = [AllowAny]


		class UpdateNotificationAPIView(UpdateAPIView):

Notification Model and Endpoints #286

Notification Model and Endpoints #286

Conversation

zorazrr commented Feb 11, 2022 • edited Loading