Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Add experimental "dont_push" push action to suppress push for notifications #6061

Closed
wants to merge 2 commits into from

Commits on Sep 18, 2019

  1. Add experimental "dont_push" push action to suppress push for notific…

    …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).
    ara4n committed Sep 18, 2019
    Configuration menu
    Copy the full SHA
    2292dc3 View commit details
    Browse the repository at this point in the history

Commits on Sep 19, 2019

  1. changelog

    ara4n committed Sep 19, 2019
    Configuration menu
    Copy the full SHA
    dd8e24f View commit details
    Browse the repository at this point in the history