Skip to content

Warn when haven't successfully sent notification token to server #323

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

Open
gnprice opened this issue Oct 16, 2023 · 3 comments
Open

Warn when haven't successfully sent notification token to server #323

gnprice opened this issue Oct 16, 2023 · 3 comments

Comments

@gnprice
Copy link
Member

gnprice commented Oct 16, 2023

This is part of the notification troubleshooting screen, and warning banners leading to it, that we have on zulip-mobile. We should build something similar here.

@gnprice
Copy link
Member Author

gnprice commented Mar 27, 2025

One particularly important situation we'll want this to cover: in the coming months we hope to implement end-to-end encryption of push notifications, zulip/zulip#6954. When we do, we expect to include a setting where realm admins can say that E2E-encrypted push notifications are the only kind of push notification available — meaning that clients from before we implement the feature won't be able to receive push notifications.

Because a large minority of users have the mobile app update only slowly (weeks or months after a new version is released), when that feature is new, enabling that setting will mean a large swath of users will stop getting push notifications. So it'd be valuable to have appropriate error-handling, and warnings to the user, out well before the feature itself, so that most of those users are at least on a version that has the error-handling and will tell them what's wrong.

In particular, this means:

  • We'll need to be careful with Dedupe sending notification token to server #322: if the client successfully sent the notification token in the past, but now their realm admins have enabled the new "E2E notifications only" setting, we need the client to realize there's a problem.
  • The troubleshooting UI should include any error-message text which the server sent back on a failed attempt to send the notification token. That way, the eventual implementation of E2E notifications can supply whatever error message we decide is appropriate then, and it'll be visible for users with old versions of the app from before we built that feature.

@tomlin7
Copy link
Contributor

tomlin7 commented Mar 31, 2025

Hey @gnprice
Is the design for this ready? I see this is included in M5b milestone and was wondering if it's possible to contribute to this at this stage.

@gnprice
Copy link
Member Author

gnprice commented Apr 1, 2025

Good question. There isn't a design for this in Figma, and I think we won't necessarily have one before the app launch.

So the approach I'd like to take for the design of this is:

  • For what information is present and the basic shape of how it's organized, start as a model from what we have in the zulip-mobile legacy app.
  • For the detailed visual appearance, use off-the-shelf Material widgets, like we do in the existing few settings screens in the app.

From there we can iterate as we see things we'd like to change, but I think that will make an effective starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

2 participants