Change Details

As part of {T321527}, the #growth-team is working on adding support for conditional user defaults (in the first iteration, based on `user_registration` only). In this task, we should make use of conditional user defaults in the Echo codebase. During this process, we need to be cautious about users who currently have the defaults set. In the database, using the default user property value is represented as "nothing is written in the database" and as such, if we change the default value, we need to add rows for users where there previously were no records. Within this task, we should replace the majority of user_properties rows for the following properties (properties inserted in `Hooks:: getNewUserPreferenceOverrides` for all new users in Echo) with conditional defaults: * `echo-subscriptions-web-reverted` * `echo-subscriptions-web-article-linked` * `echo-subscriptions-email-mention` * `echo-subscriptions-email-article-linked` For more details, see T54777#9139837 and T333531#8778414. This logic was introduced in April 2013 in [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/60779). ### Deployment plan One of the complexities associated with the deployment lies with the fact that changing user property defaults affects all users that do not have a specific row in `user_properties`. This can be resolved by temporarily inserting rows to `user_properties` for all post-2013 users (so that the default values are not actually used). Unfortunately, that is not easily possible, because `UserOptionsManager` automatically drops rows from user_properties if they happen to match the current default. To workaround that, we can make use of the fact that all of the affected properties (see above) are booleans and that true/false can be constructed by casting specific integers or strings (eg. `(bool)2` evaluating to `true` etc.). This is possible, because both usages of the properties (Special:Preferences and Echo itself) do not really care whether the user option is true or false; they only care about their truthiness/falsiness when casted to a bool. In this plan, I decided to go with `0` to represent `false` and `2` to represent `true`. Implementation-wise, we would: 1. In WMF config, set the default for `echo-subscriptions-web-reverted` to `2` (as its current default is `true`) and the default for `echo-subscriptions-web-article-linked`, `echo-subscriptions-email-mention` and `echo-subscriptions-email-article-linked` to `''` (as their current default is `false`). This should not have any impact other than rows being inserted for all users. * Beta patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987963, followed by https://gerrit.wikimedia.org/r/990730 2. Run `userOptions.php` and ensure all users that registered post-2013 (when the change of defaults happened) have rows in user_properties * Requires {T354417} to be resolved first * Once the task gets resolved, we'd run commands like the following (and similar): * `foreachwiki userOptions.php --old-is-default --old=2 --new 1 --nowarn --dry 'echo-subscriptions-web-reverted'` * `foreachwiki userOptions.php --old-is-default --old=0 --new '' --nowarn --dry 'echo-subscriptions-web-article-linked'` 3. Enable conditional defaults for echo properties and drop the temporary defaults overrides from step 1 * Example patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987964 4. Backup the `user_properties` table. 5. Drop all the now-redundant rows (ie. rows where the up_value matches the now-default). For `enwiki`, the above plan should be executed per-property (eg. do one property first, clean-up, and then move to the next), in order to avoid creating an extremely large table. We should also verify the plan's viability at beta-cluster and `testwiki` first. === QA Testing notes: - We should test to ensure that nothing changes. - Comparison testing: Test accounts that registered before the change in Echo (ie. pre-2013) and after the change. If not possible, `user_registration` can be updated manually.

As part of {T321527}, the #growth-team is working on adding support for conditional user defaults (in the first iteration, based on `user_registration` only). In this task, we should make use of conditional user defaults in the Echo codebase. During this process, we need to be cautious about users who currently have the defaults set. In the database, using the default user property value is represented as "nothing is written in the database" and as such, if we change the default value, we need to add rows for users where there previously were no records. Within this task, we should replace the majority of user_properties rows for the following properties (properties inserted in `Hooks:: getNewUserPreferenceOverrides` for all new users in Echo) with conditional defaults: * `echo-subscriptions-web-reverted` * `echo-subscriptions-web-article-linked` * `echo-subscriptions-email-mention` * `echo-subscriptions-email-article-linked` For more details, see T54777#9139837 and T333531#8778414. This logic was introduced in April 2013 in [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/60779). ### Deployment plan One of the complexities associated with the deployment lies with the fact that changing user property defaults affects all users that do not have a specific row in `user_properties`. This can be resolved by temporarily inserting rows to `user_properties` for all post-2013 users (so that the default values are not actually used). Unfortunately, that is not easily possible, because `UserOptionsManager` automatically drops rows from user_properties if they happen to match the current default. To workaround that, we can make use of the fact that all of the affected properties (see above) are booleans and that true/false can be constructed by casting specific integers or strings (eg. `(bool)2` evaluating to `true` etc.). This is possible, because both usages of the properties (Special:Preferences and Echo itself) do not really care whether the user option is true or false; they only care about their truthiness/falsiness when casted to a bool. In this plan, I decided to go with `0` to represent `false` and `2` to represent `true`. Implementation-wise, we would: 1. In WMF config, set the default for `echo-subscriptions-web-reverted` to `2` (as its current default is `true`) and the default for `echo-subscriptions-web-article-linked`, `echo-subscriptions-email-mention` and `echo-subscriptions-email-article-linked` to `''` (as their current default is `false`). This should not have any impact other than rows being inserted for all users. * Beta patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987963, followed by https://gerrit.wikimedia.org/r/990730 2. Run `userOptions.php` and ensure all users that registered post-2013 (when the change of defaults happened) have rows in user_properties * Requires {T354417} to be resolved first * Once the task gets resolved, we'd run commands like the following (and similar): * `foreachwiki userOptions.php --old-is-default --old=2 --new 1 --nowarn --dry 'echo-subscriptions-web-reverted'` * `foreachwiki userOptions.php --old-is-default --old=0 --new '' --nowarn --dry 'echo-subscriptions-web-article-linked'` * Verify no users have missing user_properties rows by running a SQL query, such as `select user_name from user where user_id not in (select up_user from user_properties where up_property='echo-subscriptions-web-reverted');`. 3. Enable conditional defaults for echo properties and drop the temporary defaults overrides from step 1 * Example patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987964 4. Backup the `user_properties` table. 5. Drop all the now-redundant rows (ie. rows where the up_value matches the now-default). For `enwiki`, the above plan should be executed per-property (eg. do one property first, clean-up, and then move to the next), in order to avoid creating an extremely large table. We should also verify the plan's viability at beta-cluster and `testwiki` first. === QA Testing notes: - We should test to ensure that nothing changes. - Comparison testing: Test accounts that registered before the change in Echo (ie. pre-2013) and after the change. If not possible, `user_registration` can be updated manually.

As part of {T321527}, the #growth-team is working on adding support for conditional user defaults (in the first iteration, based on `user_registration` only). In this task, we should make use of conditional user defaults in the Echo codebase. During this process, we need to be cautious about users who currently have the defaults set. In the database, using the default user property value is represented as "nothing is written in the database" and as such, if we change the default value, we need to add rows for users where there previously were no records. Within this task, we should replace the majority of user_properties rows for the following properties (properties inserted in `Hooks:: getNewUserPreferenceOverrides` for all new users in Echo) with conditional defaults: * `echo-subscriptions-web-reverted` * `echo-subscriptions-web-article-linked` * `echo-subscriptions-email-mention` * `echo-subscriptions-email-article-linked` For more details, see T54777#9139837 and T333531#8778414. This logic was introduced in April 2013 in [this patch](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/60779). ### Deployment plan One of the complexities associated with the deployment lies with the fact that changing user property defaults affects all users that do not have a specific row in `user_properties`. This can be resolved by temporarily inserting rows to `user_properties` for all post-2013 users (so that the default values are not actually used). Unfortunately, that is not easily possible, because `UserOptionsManager` automatically drops rows from user_properties if they happen to match the current default. To workaround that, we can make use of the fact that all of the affected properties (see above) are booleans and that true/false can be constructed by casting specific integers or strings (eg. `(bool)2` evaluating to `true` etc.). This is possible, because both usages of the properties (Special:Preferences and Echo itself) do not really care whether the user option is true or false; they only care about their truthiness/falsiness when casted to a bool. In this plan, I decided to go with `0` to represent `false` and `2` to represent `true`. Implementation-wise, we would: 1. In WMF config, set the default for `echo-subscriptions-web-reverted` to `2` (as its current default is `true`) and the default for `echo-subscriptions-web-article-linked`, `echo-subscriptions-email-mention` and `echo-subscriptions-email-article-linked` to `''` (as their current default is `false`). This should not have any impact other than rows being inserted for all users. * Beta patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987963, followed by https://gerrit.wikimedia.org/r/990730 2. Run `userOptions.php` and ensure all users that registered post-2013 (when the change of defaults happened) have rows in user_properties * Requires {T354417} to be resolved first * Once the task gets resolved, we'd run commands like the following (and similar): * `foreachwiki userOptions.php --old-is-default --old=2 --new 1 --nowarn --dry 'echo-subscriptions-web-reverted'` * `foreachwiki userOptions.php --old-is-default --old=0 --new '' --nowarn --dry 'echo-subscriptions-web-article-linked'` * Verify no users have missing user_properties rows by running a SQL query, such as `select user_name from user where user_id not in (select up_user from user_properties where up_property='echo-subscriptions-web-reverted');`. 3. Enable conditional defaults for echo properties and drop the temporary defaults overrides from step 1 * Example patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/987964 4. Backup the `user_properties` table. 5. Drop all the now-redundant rows (ie. rows where the up_value matches the now-default). For `enwiki`, the above plan should be executed per-property (eg. do one property first, clean-up, and then move to the next), in order to avoid creating an extremely large table. We should also verify the plan's viability at beta-cluster and `testwiki` first. === QA Testing notes: - We should test to ensure that nothing changes. - Comparison testing: Test accounts that registered before the change in Echo (ie. pre-2013) and after the change. If not possible, `user_registration` can be updated manually.