-
Notifications
You must be signed in to change notification settings - Fork 30
[Feature] Custom notification settings #1272
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
Conversation
074b8c7 to
a2e5b9b
Compare
c1aba40 to
eaa3390
Compare
a2e5b9b to
65f9bbe
Compare
e05d4f2 to
6bae56c
Compare
65f9bbe to
07863d2
Compare
6bae56c to
7d164b1
Compare
77ba641 to
e88753b
Compare
7d164b1 to
c6e6807
Compare
e88753b to
1d6efed
Compare
c6e6807 to
5d0bccd
Compare
1d6efed to
fecc14a
Compare
5d0bccd to
07d0603
Compare
fecc14a to
905071b
Compare
07d0603 to
7f7b1bf
Compare
1debff7 to
8e10dec
Compare
|
Depending on the order of merging. Do you want the branch to be merged to main. Or in the dev branch. I leave the merge order up to you. |
You can now set custom notification settings for users, magazine, entries and posts: `Loud`, `Default` or `Muted`. Move the logic of "fetch an endpoint and get html. Replace html node with selector x with the result of the fetch" to another controller, so it can be used outside of subjects (`Entry`, `EntryComment`, `Post` and `PostComment`)
- if the magazine was not on default (e.g.: on loud) and you had "notify on replies" enabled it didn't work -> fix that - rename some variables for readability - add log statement with all the variables
By fixing the tests I discovered that nested comments don't trigger a notification for the author of the entry anymore. Fix that bug and the tests
- the bookmark_list component was forgotten when moving the linkCallback code into the new html-refresh controller
6a1fe25 to
00fc43e
Compare
| $dontNeedSubscriptionString = $dontNeedSubscription ? 'true' : 'false'; | ||
| $dontNeedToBeAuthorString = $dontNeedToBeAuthor ? 'true' : 'false'; | ||
|
|
||
| $sql = "SELECT u.id FROM \"user\" u |
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.
This query looks very heavy. Did you perform benchmarks on this new query? We already have too many long duration queries, so hopefully this query is not taking long to execute?
And I'm talking about a server with many users and magazines of course (a real world scenario).
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.
Nope I didn't test or benchmark this query, but imo it only looks heavy, but is actually not for a database server. It has just a big where statement which means it will not go through that many table rows.
I would love to benchmark it, but I have no idea how I would do that
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 would love to have some performance tracing lines in Mbin, but I digress..
Regarding PostgreSQL queries, try to get real life performance duration by setting log_min_duration_statement in postgresql. And check the postgresql logs. Like in this issue: #1230 (comment)
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.
Ok, I activated it with a 1 second log_min_duration_statement. But I doubt that my server is a good benchmark
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.
maybe set it to 500ms instead ;)? Which is also very long (too long) for a query.
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 had it at the setting for 5 days and I have gotten notifications in the mean time: when I run cat /var/log/postgresql/postgresql-16-main.lo1g | grep LEFT\ JOIN\ notification_settings I get an empty response. So I'd say the performance is safe :)
- the custom notification component was shown on all posts in the timeline when viewing microblog posts
You can now set custom notification settings for users, magazine, entries and posts:
Loud,DefaultorMuted.The heart of the logic is in the method
NotificationSettingsRepository::findNotificationSubscribersByTargetwhich replaced some logic in the notification managers.The logic works in tiers:
So if you muted the magazine and thread, but the author is set to "Loud" then you will still get notifications for threads created by them.
If you muted the user, but set the magazine to "Loud" then you will get notifications for threads that are not created by that muted user.