Per our meeting we will pass user authorization as a string with the values provided by apple as documented here:
https://developer.apple.com/documentation/usernotifications/unauthorizationstatus

Changed device_level_enabled data type to "string" to allow for variables other than TRUE/FALSE.
New Revision #: 22479505

@Mazevedo here's a breakdown of what we'll need to do for this.

1. Update UserHistoryFunnel.swift to target Shay's latest schema version (mentioned in her comment above ^). To do this, simply update this line to super.init(schema: "MobileWikiAppiOSUserHistory", version: 22479505)
2. Now in the funnel's event() method, you'll want to add code that sets the event's "inbox_count" key and "device_level_enabled" key to these values:

• You can get the device_level_enabled value by calling UserHistoryFunnel's dataStore.notificationsController.notificationPermissionsStatus(completion:) method. This is an asynchronous method that will return a UNAuthorizationStatus value. You can assign descriptive strings representing this value to the event's "device_level_enabled" key.
• In a similar manner, the "inbox_count" value will need to come from UserHistoryFunnel's dataStore.remoteNotificationsController (it is a RemoteNotificationsController type). We don't yet have a method to call here that will return us the count. You'll need to write a new public method in RemoteNotificationsController that returns the count of all notifications in the RemoteNotifications Core Data database. You can take a look at the existing fetchNotifications method as inspiration. It should be simple to set up a similar NSFetchRequest like that method and get a count from it. Then assign this resulting value to your event's "inbox_count".

That should take care of most of this task. Once you get this hooked up, you can start inspecting via ProxyMan to test what values your event is sending, just how you did with the theming bug fix. We may have some followups where we need to make sure the event gets triggered once a day, but don't worry about that part yet.

For the device_level_enabled type, we're sending strings that represent the UNAuthorizationStatus values:

• notDetermined (before the user enables/disables notifications)
• denied
• authorized
• provisional (when the user has authorized "quiet" notifications)
• ephemeral (a temporary type of notifications on App Clips)

@JMinor checking on the MobileWikiAppiOSUserHistory logging process, it posts snapshots of the events under two circumstances:

• When the app launches or resumes
• When the user toggles the Send Usage Reports switch (when the user turns it off, we send one last snapshot of their activity).

We always check if the event that is about to be logged is identical to the last one that was posted, but it might be possible that a user has their MobileWikiAppiOSUserHistory event logged more than once a day.
Let me know if you think we should change this.

@Mazevedo Thanks for digging into it! I also think it's possible that if the app is left alone in a terminated, backgrounded, or suspended state for multiple days, this event won't be posted. I could be wrong - we might be able to have @SNowick_WMF dig into the data on her side to see if there are clearly multiple days missing in between for these events for the same user.

@JMinor @SNowick_WMF The data portion of this task for this is done and merged. Let us know if you want us to try adjusting the cadence of how often this event gets posted (we think currently it could be either multiple times a day or not at all if the app state is not active). For bumping up the frequency, we could try adding a BGAppRefreshTaskRequest with an earliestBeginDate being set to the next day to try and coax the app into launching in the background one day later and posting this event. Note that this is no guarantee it'll happen though, iOS prioritizes what it wants to with background tasks.

Going to move this into blocked for now till we hear feedback. Thanks!

I will investigate data cadence and questions as detailed here, thanks @Tsevener and @Mazevedo - made new ticket assigned to me https://phabricator.wikimedia.org/T298820

Notes: Adding from origin docs for MobileWikiAppiOSUserHistory, this explains why we're seeing multiple rows per day for some users and daily unique counts are lower than daily active unique counts in other tables.

When users first open the app after install or update, we record these properties values (initial state) locally and send them to event logging server. At the end of each session, we take a snapshot of these properties: if ANY of these properties’ values have been changed comparing to user’s last snapshot, we send the new snapshot to the server with ALL properties values, the session_end timestamp and the session_id. If NONE of these properties’ values has changed, we won’t send the snapshot.

Data has been validated for version 6.9.0.1922, values for inbox_count and device_level_enabled now populated in MobileWikiAppiOSUserHistory.