Ask for notification permission when enabling account notifications

[cketti]

Currently the app is only asking for the notification permission during onboarding. But if the user doesn't grant the permission then, the app should ask again when the user enables notifications for an account (either when adding an additional account or via account settings).

We'll also have to handle the case where the user has denied the permission already and point them to the correct Android screen to reverse that decision.

Open question: What should the app do when it notices the notification permission has been revoked, but notifications are enabled inside the app?

[Aditya13s]

can i work on this issue? @cketti

[kewisch]

@Aditya13s I know it has been a while, but if you are interested, do you have some thoughts on cketti's open question?

[Renekakpo]

Hello @kewisch !
I'm interested in working on this issue and would like to be assigned. Could you assign this to me?

[kewisch]

@Renekakpo extending my question to you then, do you have thoughts on cketti's open question?

[Renekakpo]

I agree to cketti's approach on how to handle the notification problem. For the open question, I would suggest the following approach:

• When notification is permanently denied
  • Detect permission revocation
  • Silently disable in-app notifications
  • Provide a clear, non-intrusive way for users to re-enable permissions
• Otherwise
  • Attempt to re-establish notification capabilities

@kewisch Let me know what are your thoughts on my suggestion.

[kewisch]

@Renekakpo how are you planning to inform the user that notifications are silently disabled and allow them to re-enable? Could you describe the UX here?

[Renekakpo]

Sure! When users open the app, we can display a notification status banner at the top of the notification preferences, user account settings, or global app settings screen. The banner would use a muted color to indicate status neutrally, not as an error. It will explain to the user why this view is present and what action they should take.
The banner will be:
- Persistent but non-intrusive
- Consistent with the app's design language
- Featuring a clickable "Re-enable" text

On user interaction, the app will:

• Request permission through the standard flow
• If permission is permanently denied, show a rationale explanation with a direct "Open Settings" button
• Allow users to easily re-enable notifications

I believe, this approach ensures users are informed about their notification status without creating friction, providing a clear and straightforward path to re-enabling notifications.

[kewisch]

I'm still having trouble concretely understanding what the flow looks like here. When would you show this banner? Is it in-app, or a system notification? What happens if the user does not want to re-enable? How would the rationale be shown? In what way would users be able to easily re-enable notifications? What UI Elements were you planning to use?

You are welcome to get started on the patch without all those questions answered, me asking is just trying to avoid double work for you in the end if the approach needs to be changed. Maybe just go ahead for now and we can get back to the questions later.

[Renekakpo]

Hi @kewisch,
Great questions. Let me break down my suggestion more concretely:

When to Show the Banner:

• Inside the app, specifically in settings screens or related screen
• Triggered when the app detects notification permissions have been revoked
• Visible when the user navigates to notification-related settings

Banner Details:

• An in-app banner (not a system notification)
• Located at the top of relevant settings screens
• Uses a neutral, non-alarming color scheme
• Brief, clear text explaining the notification status

User Interaction Options:

• 'Re-enable' button leads to permission request
• If user declines, show a dialog explaining the benefits of notifications
• Option to permanently dismiss the banner

Rationale Explanation:

• A simple dialog with:
  • Why notifications are valuable
  • How they improve app experience
  • Clear, non-technical language

Re-enabling Mechanism:

• In-app permission request
• Direct link to system notification settings
• Simple, one-tap process

I'm open to iterating on this approach. Would you like me to start implementing and we can refine the details as we go?