-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add push notification filtering settings #3207
Conversation
UncleSamtoshi
commented
Sep 13, 2023
•
edited
Loading
edited
- Adds the ability to set and retrieve push notification filters
- Push Notifications will be on by default and before they are sent we will check to make sure notifications are enabled and that the individual notification type and subtype is not disabled
- NOTE: This is implemented using a string for NotificationType instead of an enum. This allows for the notification service to not need any context about the notifications that are passing through it.
b409b74
to
2c45ce1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some comments
src/graphql/public/root/mutation/account-update-push-notification-settings.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have the same reservation on the ambiguity regarding the usage of the mutations with the current API.
the query looks fine.
aadb6c4
to
3a0d2d3
Compare
bba12c7
to
54771b2
Compare
a1ae361
to
337cffe
Compare
...sendNotificationArgs, | ||
data: { | ||
...data, | ||
NotificationCategory: notificationCategory, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what is supposed to be inside { data } versus at the root level (ie: { ...sendNotification, ... }
) but reading here would make me think NotificationCategory: notificationCategory,
is more a metadata thing and should be one level up in the root
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, I will move it up a level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I think it may make sense to keep it where it is at. It is preferable that all notifications that have a notification category receive it as a part of their metadata. Since this method already has logic relating to handling notification categories I think it is alright for it to augment the metadata.
@@ -0,0 +1,28 @@ | |||
import { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering how much we should add to the legacy-integration
. We're aiming at trimming this folder down. @vindard would have more context
great PR. looks good overall, some nits to look at. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approving, even if this may need change. someelse can reapprove later.