Messages counters are disabled if notifications for group chats are disabled #528
Comments
lampholder
added
P2
A-Notifications
T-Defect
S-Minor
|
I'm in two minds as to how to categorize this - it certainly seems unexpected that unread message count functionality would be coupled to notifications, so I'm leaning towards its being a bug. Related: #1359 element-hq/element-web#3389. Could be tackled as part of #1359. |
|
the current designed behaviour is "badge count shows number of missed notifs". I agree it could be useful though to have the count reflect messages even if you didn't get a notif for them though. This is a new feature tho. |
|
+1 for decoupling the two |
…ations This is a potential solution to https://github.com/vector-im/riot-web/issues/3374 and element-hq/element-web#5953 as raised by Mozilla at element-hq/element-web#10868. This lets you define a push rule action which increases the badge count (unread notification) count on a given room, but doesn't actually send a push for that notification via email or HTTP. We might want to define this as the default behaviour for group chats in future to solve https://github.com/vector-im/riot-web/issues/3268 at last. This is implemented as a string action rather than a tweak because: * Other pushers don't care about the tweak, given they won't ever get pushed * The DB can store the tweak more efficiently using the existing `notify` table. * It avoids breaking the default_notif/highlight_action optimisations. Clients which generate their own notifs (e.g. desktop notifs from Riot/Web would need to be aware of the new push action) to uphold it. An alternative way to do this would be to maintain a `msg_count` alongside `highlight_count` and `notification_count` in `unread_notifications` in sync responses. However, doing this by counting the rows in `events` since the `stream_position` of the user's last read receipt turns out to be painfully slow (~200ms), perhaps due to the size of the events table. So instead, we use the highly optimised existing event_push_actions (and event_push_actions_staging) table to maintain the counts - using the code paths which already exist for tracking unread notification counts efficiently. These queries are typically ~3ms or so. The biggest issues I see here are: * We're slightly repurposing the `notif` field on `event_push_actions` to track whether a given action actually sent a `push` or not. This doesn't seem unreasonable, but it's slightly naughty given that previously the field explicitly tracked whether `notify` was true for the action (and as a result, it was uselessly always set to 1 in the DB). * We're going to put more load on the `event_push_actions` table for all the random group chats which people had previously muted. In practice i don't think there are many of these though. * There isn't an MSC for this yet (although this comment could become one).
|
The current set-up breaks Kent Pitman's two-bit rule. |
|
Hello all! |
|
This is a spec issue, the server-side (unread) notification counters are not provided when you disable notifications (because they're notification counters after all) |
I don't need notifications for every single message in group chats. So I turned them off but counters for messages disappeared. I need to know number of unread messages per chat but I don't want to get spammed with notifications.
If desktop notifications is on and notifications for group chats is on there are counters present but I get unwanted notifications.
If desktop notifications is on and notifications for group chats is off no counters and no unwanted notifications.
I think there should be a way to see counters and receive notification only on mentioning.
The text was updated successfully, but these errors were encountered: