-
Notifications
You must be signed in to change notification settings - Fork 16
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
[Feature] Custom notification settings #1272
base: main
Are you sure you want to change the base?
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.
You can now set custom notification settings for users, magazine, entries and posts:
Loud
,Default
orMuted
.The heart of the logic is in the method
NotificationSettingsRepository::findNotificationSubscribersByTarget
which 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.