Disabling notifications also make incoming call not working
See original GitHub issueNext steps:
The decision has been made to keep the behaviour the same but update the copy so that users understand the impact of disabling notifications this way.
Design will need to provide suggested copy and the desired delivery of such method for discussion with the team (sub-text, pop-up, etc)
Original Issue:
The problem is only observed when the application is on background, which I assume is the case most of the time
When user disables the notifications, at account level or at session level from the settings of the app:
![image](https://user-images.githubusercontent.com/3940906/92243199-5e838d80-eec1-11ea-94f1-1af82dbb593b.png)
It’s not mentioned that a side effect is that no sync will be performed anymore when the app is in background and so the application cannot be aware of any incoming calls.
Possible quick fix
We should modify the wording of the settings to warn the user about this (maybe but probably) unexpected side effect.
Possible fix 1
When user disable the notification the app will not remove the pusher, but will modify the push rule to not filter out the incoming call event (m.call.invite
). It will not work for encrypted rooms, so we will receive a push for all events from e2e.
Possible fix 2
Have a special sync thread to handle call signaling, which is always running, even if notification are disable (same pb for e2e rooms)
Possible fix 3
When unchecked, the setting “Enable notifications for this session” will not remove the pusher, but just make the app not display any notifications for messages at all (so the app will only display incoming call notification).
We could add another setting to fully remove the pusher, and which explicitly warn the user that incoming call will not work when the app is in background.
Other possible fix?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
ok, some thoughts on this.
First of all, e2e rooms are a big problem here: currently, you have to decrypt every event to check if it is a voip call. https://docs.google.com/document/d/1--jNzeyNn61EllbmFw6zAS1Oj8-i3JBfF_sCBI5CgiA/edit#heading=h.2dri2t8s1xsd proposes to address this by moving some metadata outside the event. So I think that will be the medium-term solution there.
It seems to me that the client should be able to configure the server to only send pushes for voip calls (so basically, fix 1). However, push rules are going away, so my suggestion is that we either park this or make the quick fix for now, and consider how to resolve it properly in a post-push-rules world. I’ll make sure to consider this in my notifications rework.
Product decision: Update the copy.
Disabling notifications means just that, we can add sub-text or a warning that this removes all notifications including calls.
Removing the Needs-Product label.
Next steps: Design