Change Details

When a user is logged and in opts into beta mode in Special:MobileOptions we set a preference, but this is not logged in Schema:PrefUpdate. It should be. ###Problem Currently WikimediaEvents [[ https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L280 | Hook ]] listens to [[https://www.mediawiki.org/wiki/Manual:Hooks/UserSaveOptions | UserSaveOptions ]] hook, and when the user changes preferences it tracks the change in [[https://meta.wikimedia.org/wiki/Schema:PrefUpdate | PrefUpdate schema ]]. The [[ https://www.mediawiki.org/wiki/Reading/Web/Mobile_Beta | Mobile Beta Mode ]] (do not mix with [[ https://www.mediawiki.org/wiki/Beta_Features | Beta Features ]]) preferences is stored in UserOptions, so it supposedly, all Mobile Beta Mode switches should be tracked by `PrefUpdate` schema. This doesn't happen because [[https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L289 | WikimediaEventsHooks::onUserSaveOptions ]] logic tracks the Analytics Events only when `User::saveOptions` was called on: - Special:Preferences - via API `action=options` call All other events are just ignored. This is expected as most probably we don't want to track user preferences when user object is created (user creation) and during maintenance scripts. ###Why? We're planning to store the `Advanced Mobile Contributions` preference as UserOption and track user retention. The `PrefUpdate` schema looks like the best candidate but because of `WikimediaEventsHooks:onUserSaveOptions` logic we cannot use it. ###Open questions - why WikimediaEvents tracks `PrefUpdate` only on `Special:Preferences` page submits and `action=options` API calls? - can we remove that logic and track `PrefUpdate` on any page? There are not that many places that call `User::saveSettings`, definitely we have to not track events on maitenanceScripts, what about other places? ###Developer notes: The safest way is to just to add `$title->isSpecial('Preferences') || $title->isSpecial('MobileOptions')`, but maybe there is something we can improve. There is a TODO in code > // TODO (mattflaschen, 2013-06-13): Ideally this would be done more cleanly without > // looking explicitly at page names and URL parameters. > // Maybe a userInitiated flag passed to saveSettings would work.

When a user is logged and in opts into beta mode in Special:MobileOptions we set a preference, but this is not logged in Schema:PrefUpdate. It should be. ###Problem Currently WikimediaEvents [[ https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L280 | Hook ]] listens to [[https://www.mediawiki.org/wiki/Manual:Hooks/UserSaveOptions | UserSaveOptions ]] hook, and when the user changes preferences it tracks the change in [[https://meta.wikimedia.org/wiki/Schema:PrefUpdate | PrefUpdate schema ]]. The [[ https://www.mediawiki.org/wiki/Reading/Web/Mobile_Beta | Mobile Beta Mode ]] (do not mix with [[ https://www.mediawiki.org/wiki/Beta_Features | Beta Features ]]) preferences is stored in UserOptions, so it supposedly, all Mobile Beta Mode switches should be tracked by `PrefUpdate` schema. This doesn't happen because [[https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L289 | WikimediaEventsHooks::onUserSaveOptions ]] logic tracks the Analytics Events only when `User::saveOptions` was called on: - Special:Preferences - via API `action=options` call All other events are just ignored. This is expected as most probably we don't want to track user preferences when user object is created (user creation) and during maintenance scripts. ###Why? We're planning to store the `Advanced Mobile Contributions` preference as UserOption and track user retention. The `PrefUpdate` schema looks like the best candidate but because of `WikimediaEventsHooks:onUserSaveOptions` logic we cannot use it. ##Open questions ####Why WikimediaEvents tracks `PrefUpdate` only on `Special:Preferences` page submits and `action=options` API calls? Answer: It's done this way to limit all analytics events only to user actions. We don't want to track `PrefUpdate` when maitenance script or custom logic enables features for users. ####Can we remove that logic and track `PrefUpdate` on any page? There are not that many places that call `User::saveSettings`, definitely we have to not track events on maitenanceScripts, what about other places? Answer: No, there are pages that update user options and we don't want to track those (because that are not user initiated actions), for example, we don't want to track: - an ongoing experiment where we enable HelpPanel to 50% of users (https://phabricator.wikimedia.org/diffusion/EGRE/browse/master/includes/HelpPanelHooks.php$60), this shouldn't be tracked - we override the default Page previews `isEnabled` state to all new accounts (https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/includes/PopupsHooks.php#L158) Most probably there are more situations like two mentioned above. ###Developer notes: The safest way is to just to add `$title->isSpecial('Preferences') || $title->isSpecial('MobileOptions')`, but maybe there is something we can improve. There is a TODO in code > // TODO (mattflaschen, 2013-06-13): Ideally this would be done more cleanly without > // looking explicitly at page names and URL parameters. > // Maybe a userInitiated flag passed to saveSettings would work.

When a user is logged and in opts into beta mode in Special:MobileOptions we set a preference, but this is not logged in Schema:PrefUpdate. It should be. ###Problem Currently WikimediaEvents [[ https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L280 | Hook ]] listens to [[https://www.mediawiki.org/wiki/Manual:Hooks/UserSaveOptions | UserSaveOptions ]] hook, and when the user changes preferences it tracks the change in [[https://meta.wikimedia.org/wiki/Schema:PrefUpdate | PrefUpdate schema ]]. The [[ https://www.mediawiki.org/wiki/Reading/Web/Mobile_Beta | Mobile Beta Mode ]] (do not mix with [[ https://www.mediawiki.org/wiki/Beta_Features | Beta Features ]]) preferences is stored in UserOptions, so it supposedly, all Mobile Beta Mode switches should be tracked by `PrefUpdate` schema. This doesn't happen because [[https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L289 | WikimediaEventsHooks::onUserSaveOptions ]] logic tracks the Analytics Events only when `User::saveOptions` was called on: - Special:Preferences - via API `action=options` call All other events are just ignored. This is expected as most probably we don't want to track user preferences when user object is created (user creation) and during maintenance scripts. ###Why? We're planning to store the `Advanced Mobile Contributions` preference as UserOption and track user retention. The `PrefUpdate` schema looks like the best candidate but because of `WikimediaEventsHooks:onUserSaveOptions` logic we cannot use it. ###Open questionsOpen questions ####Why WikimediaEvents tracks `PrefUpdate` only on `Special:Preferences` page submits and `action=options` API calls? Answer: It's done this way to limit all analytics events only to user actions. We don't want to track `PrefUpdate` when maitenance script or custom logic enables features for users. ####Can we remove that logic and track `PrefUpdate` on any page? There are not that many places that call `User::saveSettings`, definitely we have to not track events on maitenanceScripts, what about other places? Answer: No, there are pages that update user options and we don't want to track those (because that are not user initiated actions), for example, we don't want to track: - why WikimediaEvents tracks `PrefUpdate` only on `Special:Preferences` page submits and `action=options` API calls?an ongoing experiment where we enable HelpPanel to 50% of users (https://phabricator.wikimedia.org/diffusion/EGRE/browse/master/includes/HelpPanelHooks.php$60), this shouldn't be tracked - can we remove that logic and track `PrefUpdate` on any page? There are not that many places that call `User::saveSettings`, definitely we have to not track events on maitenanceScripts, what about other places? we override the default Page previews `isEnabled` state to all new accounts (https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/includes/PopupsHooks.php#L158) Most probably there are more situations like two mentioned above. ###Developer notes: The safest way is to just to add `$title->isSpecial('Preferences') || $title->isSpecial('MobileOptions')`, but maybe there is something we can improve. There is a TODO in code > // TODO (mattflaschen, 2013-06-13): Ideally this would be done more cleanly without > // looking explicitly at page names and URL parameters. > // Maybe a userInitiated flag passed to saveSettings would work.