@Dmantena, @Tsevener and I have been discussing some elements of this ticket here: https://www.figma.com/file/wx5nwf98MM5b4uOVktpcEk/Notifications-flows?node-id=0%3A1, esp re the primary toggle.

Just an FYI, this ticket might be a dupe of https://phabricator.wikimedia.org/T271855, which hasn't begun development yet. We can discuss in grooming which one we should work against, or if one is meant for design and the other development.

Thanks @Tsevener going to move this into 'blocked or waiting' for now

@JMinor should I make these changes: Keep push, remove subscriptions, add back in filters

I'm going to clean up the engineering portions of this task description to represent the requirements as I know them. Before I do this, here are the answers to the old task description questions:

[1] We need a primary toggle to enable and disable push notifications - e.g. "Enable Push Notifications"

There is now a Push Notifications toggle in the mocks.

[2] We need educational text to display that indicates the user needs to enable Notifications in iOS's Settings if the user has a. tried to toggle on Push Notifications and b. denied access to Notifications in the system prompt.

I don't see this educational text in the mocks, but there is a push denied state in Figma with an navigation arrow that I assume goes to OS Settings. @cmadeo let me know if that's right, it might be worthwhile to sync on this screen again just to make sure everything is squared away. (Edit: I see confirmation in https://phabricator.wikimedia.org/T288773. Thanks!)

[3] Are the notifications they are toggling here a. what they are opting in to see in the notification center b. what they are opting in to be pushed to their devices as push notifications (app column in Echo on web) or c. both?

My understanding is the latest ask from @JMinor is that we only have one toggle screen for push notification settings, the API details of which are listed in this task description. We will no longer have an Account > Notification subscriptions settings screen that toggles the desktop "web" checkbox preferences, thus affecting what they see or not see in the app notification center. If the user wants to change what is displayed to them in the notification center at a server-level, they will have to go to the web to change these. We may want to have some user education text for this in app notification center if it isn't there already.

Because we are moving away from tabs, we are bringing back local filtering of notification types. This is purely a local filter to allow the user to hide potential abuse.

[1] The UI needs API on the Notifications Data Controller to interact with here

The plan is for the data controller task to only be responsible for importing and refreshing notifications in the app center, and not deal with push preference settings. API for the overall push toggle (i.e. subscribing your device token to echo) has already been made in https://phabricator.wikimedia.org/T287305. The followup API calls are listed in the API Notes section of this task's description, to be called when toggling individual push types.

Note, because the global preferences API didn't work out, we will need to make this push type update API call for each app language they have set up, plus commons and wikidata.

I am moving this into Needs Design because we have a major remaining unknown before we can pick this up. Please look at my response to quote #3 in https://phabricator.wikimedia.org/T288688#7342910 @JMinor @cmadeo . If this information is correct, we will need from design:

• Any mentions of Settings > Account > Notification subscriptions to be removed from this task and Figma. We will only have the Push Notifications Settings toggle screen now.
• We should also remove the "Notifications Center - all "app notification center" types toggles are off, resulting in no notifications to see in notification center" edge case row from https://phabricator.wikimedia.org/T288773.
• New mocks in Figma if a local notification types filter screen, similar to the project inbox and the read/unread/all local filter screens. We may want to create a new UI Phabricator task to represent this UI work too.
• Maybe some education text in notification center explaining the user will need to go to the preference checkboxes in the web column on Desktop to control which notifications are downloaded from the server.

If I'm mistaken on the requirements, please ignore the bullet points :) Thanks!

@cmadeo @JMinor I also have a couple of minor questions in number 8 and 9 under "Development Notes" in the task description:

8. If the user adds new app preferred languages, make write preference flags API call on the new language wikis so they match preferences on old app languages. If this fails...try again later (TBD)?
9. Upon logout, behind the scenes unsubscribe device token from push. After logging back in, prompt them to turn push notifications back on. (TBD, need this prompt finalized by product/design). They will need to go back into Settings to resubscribe their device token.

Just need a little direction on these situations:

• If they add a new language and attempting to update their preferences to match other languages (behind the scenes) fails. I imagine maybe this is a silent fail and we just try again later at some point.
• We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Update from grooming -

1. @JMinor 's original thought is to keep the Logged in - Settings > Subscriptions screen, but instead of having it hit the server to update the web column checkbox preferences, it simply serves as a local filter to keep certain notification types from appearing in Notification Center. The filter screens within Notification Center are meant more as fleeting tools to allow the users to more easily find certain notifications, but the Logged in - Settings > Subscriptions is meant more as a "hide forever" functionality for users that, say, never want to see Thanks. But under the hood they act the same, as a local filter. @cmadeo is going to finish up some thoughts around designing Logged in - Settings > Subscriptions as a filter screen, then we will discuss both options tomorrow in planning.

If they add a new language and attempting to update their preferences to match other languages (behind the scenes) fails. I imagine maybe this is a silent fail and we just try again later at some point.

No strong opinions of this from @JMinor , maybe to see where else we are doing progressive retry attempts (look at reading lists) and follow those patterns.

We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Any sort of keeping track of a username will be too gross and have privacy issues. The thoughts on this are that we do keep track if the device once successfully subscribed their device token to push (so just a simple UserDefaults success flag would work), we unsubscribe them upon log out, then check this flag upon log in. After checking this flag, present a modal (or integrate into existing login presentation modals) as a "heads up - you are now unsubscribed from push notifications, would you like to subscribe again?" with a button to send them to the Push Notification Settings screen (which should already be in a state with the Push Notifications parent toggle set to OFF), where they can flip the toggle again to resubscribe. @cmadeo will also look into this experience.

We are supposed to unsubscribe their device token upon logout, so what happens when they log back in? Their "Push notifications" settings toggle will be off but they may not be aware, should we let them know?

Any sort of keeping track of a username will be too gross and have privacy issues. The thoughts on this are that we do keep track if the device once successfully subscribed their device token to push (so just a simple UserDefaults success flag would work), we unsubscribe them upon log out, then check this flag upon log in. After checking this flag, present a modal (or integrate into existing login presentation modals) as a "heads up - you are now unsubscribed from push notifications, would you like to subscribe again?" with a button to send them to the Push Notification Settings screen (which should already be in a state with the Push Notifications parent toggle set to OFF), where they can flip the toggle again to resubscribe. @cmadeo will also look into this experience.

@cmadeo We just looked over https://phabricator.wikimedia.org/T287768 in engineering sync, and I think your flow "Contributor logs into app after having previously set notification settings in-app" on the Figma may have this covered. According to T287768 if the user logs out and logs back in again, they will see the push notifications prompt modal again when they visit Notifications Center, which should be enough of a heads up that they need to re-enable Push because they logged out. So I think we may be good here on the question quoted here, just letting you know.

@Tsevener sounds good. I also put some questions in Slack around this. For now I've updated the settings mocks to match the flow we discussed in the meeting today.

Hi @Tsevener I believe this is now ready for engineering, but please feel free to move back to needs design if I missed something!

@cmadeo made the tiniest of requests (just commented directly on Figma), but besides that looks great. Thanks for updating this! Moving this into Ready for Dev.

Updated! Thanks for catching that, @Tsevener

@cmadeo @JMinor we just engineering synced on this - since we haven't discussed this in a while, we wanted y'all to have one last look at the weirdest thing that jumped out to us before starting this work. There are two sets of API calls we need to make for the types section - one for READ (it set the toggles to the correct state when this section first loads) and another for WRITE (to be called when the user changes a toggle).

READ
Because global preferences didn't pan out, we need pick a particular wiki to pull their current notifications preferences from. Our plan is to just do this from the primary app language, but this does mean there's a chance that they could have a particular preference setting ON for the primary app language wiki and that same preference setting OFF for a secondary app language wiki, and the toggle will display ON when this section first loads. So it will be a bit of a misrepresentation.

WRITE
When the user toggles an option, we will gather that preference change and make the update call to each app language wiki, plus wikidata and commons.

I think this is the best we're going to get, but an alternative might be to give users some option to choose which language they want to update their push preferences from in the UI. We just need a quick thumbs up and we'll get started, otherwise we can discuss more in task sync tomorrow.

@Tsevener thanks for this write up, I'm starting to think that we might want to give users some option to choose which languages / projects based on some early feedback from the diary study, but I'm not 100% sure we're thinking about the same issue so it'd be so helpful for me to be able to talk this through at sync

FYI, this task now represents only the work on the Settings root screen (showing and hiding the Notifications cell depending on login status) and the parent push toggle on the Notification Settings screen, plus any error states if something goes wrong with push permissions or subscribing the device token. The granular types toggles will be designed and developed in a separate ticket (T302026) I changed most of this with strikethroughs for now, but I will fully delete them and move the logic once T302026 is fully defined.

PR up at https://github.com/wikimedia/wikipedia-ios/pull/4138.

Works for me on 6.9.0 (1910)