Appears to be fixed on 6.9.0 (1896)

Appears to be fixed on 6.9.0 (1896)

PR https://github.com/wikimedia/wikipedia-ios/pull/4131

Just copying and pasting Mediawiki mark as read console output errors I ran into while working on a separate task:

🚨 Error parsing JSON: Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0., NSJSONSerializationErrorIndex=0} [Session#L535]
🚨 1 of 1 mark as read requests failed [RemoteNotificationsAPIController#L270]
🚨 Error marking notifications as read or unread: individualErrors([WMF.RemoteNotificationsAPIController.MarkReadError.multiple([Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0., NSJSONSerializationErrorIndex=0}])]) [NotificationsCenterViewModel#L145]

Change 712980 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Add notifiertypes parameter to ApiEchoNotifications

https://gerrit.wikimedia.org/r/712980

In T287909#7293188, @JMinor wrote:

As for the solution, I think the "ask for both web and apps" is the second alternative I was making sure would make sense.

As for the solution, I think the "ask for both web and apps" is the second alternative I was making sure would make sense.

Hey @Mholloway first, thanks for the help here. My comments here are not meant to imply you are responsible for fixing or doing anything. You jumped back into an old project and there's no expectation you'll continue to engage or write changes for this. That said, it seems like we still have quite a bit of confusion, so I appreciate your willingness to help clarify what exists.

It's also an option for the client to opt in to push notifications for all supported types when the user first registers a token, or for a new type when support for a new type is added. (That gets into the surprise avoidance issues I mentioned earlier, but I'm done fighting that battle; do whatever you think is right.)

In T287909#7293036, @JMinor wrote:

The impact however, is that now you can only see a notification on the app's notification center if and only if you also agree to push that notification type.

Having now had a chance to digest this change with the team, I wanted to clarify what the impact will be, and the solution we're considering on iOS.

Thanks @Mholloway it does sound like an impactful enough change for its own task. Lani linked an initial ticket, and I will fill out with details.

About the defaulting behavior, after some code investigation and further thinking on the matter: it does not appear to be possible at present to set an entire notifier type to be opt-out. The recommended default, and the assumption throughout the notification preferences code, is for notifications to be opt-in, and the code for determining a user's eligibilty for receiving a notification is already complex enough that I would hesitate to add conditional user preference defaults by notifier type to the mix.

Change 712980 had a related patch set uploaded (by Mholloway; author: Michael Holloway):

[mediawiki/extensions/Echo@master] Add notifiertypes parameter to ApiEchoNotifications

https://gerrit.wikimedia.org/r/712980

@JMinor Changing that default will only take a config change. I'd say we can do it as part of this task.

This all sounds ok to me, though we should be sure to document this limitation in FAQs or other user facing info, as this may be counter-intuitive for users.

In T287909#7276438, @Tsevener wrote:

@Mholloway ah okay I think I get it - for some reason I was imagining the apps checkmark column to only be referenced by the push service to serve as a gatekeeper on which type of push notification is sent to APNS, but the user's notification center in the app can show all notifications without filters. But it probably makes more sense to the user that these line up.

Yeah, I actually didn't realize this filtering was being applied in the notifications API code, and had also assumed that it was returning all available notifications by default.