Users cannot change system notification setting if they previously denied it

[mfrey43]

Preliminary Info

What Airship dependencies are you using?

"@ua/capacitor-airship": "2.0.1",

What are the versions of any relevant development tools you are using?

Android Emulator Properties avd.ini.displayname Pixel 8 API 34 AvdId Pixel_8_API_34

targetSdkVersion = 34 firebaseMessagingVersion = '23.3.1'

Report

What unexpected behavior are you seeing?

The setUserNotificationsEnabled method only prompts the user once and has no effect after. That means if the user manually disables notifications in the native app settings, there is no way to enable it again from within the app. This is the expected behaviour on iOS and Android and I as the developer should handle it manually. The information I'm missing from this plugin is if the user can still receive a prompt or not.

What is the expected behavior?

The getNotificationStatus should not just return a boolean if notifications are allowed at the system level but also if the user can still receive a system prompt to enable them. For comparison, the official capacitor push plugin can return this info as 'granted', 'prompt' or 'denied'. This is what I am using currently. If the status is 'denied' I forward the user to the app settings where they can manually enable them. It would be great if I could solely rely on this plugin instead because having them in parallel makes the installation more complicated.

What are the steps to reproduce the unexpected behavior?

Same on Android & iOS

1. call setUserNotificationsEnabled(true)
2. deny the system prompt
3. call setUserNotificationsEnabled(true) again -> nothing happens

Do you have logging for the issue?

No

[rlepinski]

I think the best place for this would be in https://github.com/urbanairship/capacitor-airship/blob/main/src/types.ts#L95 to expose a permissionStatus: granted|denied|not_determined

But to do that we will have to do some work on the native SDK to make it possible to expose that, so it will take a few weeks. Exposing a method to either enable notifications or navigate to system settings would be an easier lift

[rlepinski]

Just an update on this, we have the changes needed on the iOS SDK pending a release hopefully this week. Once that is out ill be able to work in the notification permission to the status object and make it possible to provide options to enableUserNotifications to link to the system settings if already disabled by the user

[rlepinski]

I have some working code for Android, just need to wire up iOS next. I should be able to get this out on Monday if I don't run into any issues.

Going to have enableUserNotifications({ fallback: "settings" }) which will:

• if able to be prompted: prompt and return true if granted, false if not
• if not able to be prompted and opted out: bring user to system settings and once they get back into the app query status and return true if granted, false if not
• if already granted: return true

[rlepinski]

Found some issues with testing this:

• Android permissions status goes not_determined then immediately denied before the prompt is finished. After hitting accept it will go to granted properly but that denied status is a bug.
• There is a different behavior on Android and iOS with enableUserNotifications that I am unable to make the same without another SDK update. On Android, enableUserNotifications() will prompt and if granted, enable notifications on Airship. If denied it wont enable on Airship, so if the user goes into settings then comes back it won't be enabled on Airship still. iOS works properly here.

Due to the above, I am going to try to get another SDK release out ASAP but this plugin feature is delayed til then.