Page MenuHomePhabricator

Echo: Make use of conditional user defaults
Closed, ResolvedPublic8 Estimated Story Points

Description

As part of T321527: Support conditional defaults for user properties, 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.

New scope of task

After the original deployment plan did not succeed (see below and T353225#9520336), Growth team decided to stop new rows from getting created (handled within this task). Dropping the legacy rows was split to T357072: Echo: Drop droppable rows from user_properties.

Original deployment plan

NOTE: This ended up not working because of autocreated accounts, see T353225#9520336.

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.
  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: userOptions.php cannot be used to change user options from default to a new value 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
  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 and that new users created still have echo-subscriptions-web-reverted set to false and echo-subscriptions-web-article-linked, echo-subscriptions-email-mention and echo-subscriptions-email-article-linked to true.
  • Comparison testing: Test accounts that registered prior to February 2024 (when conditional defaults were deployed) and a newly created account.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 987963 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: Temporarily change default value for 4 Echo properties

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

Change 990730 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] beta: Temporarily change default value for 3 Echo properties

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

Change 990730 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: Temporarily change default value for 3 Echo properties

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

I verified the plan at Beta. It works well, except it turns out that 0 is a better value to represent false in the default hacking. Updated the description to reflect that.

Mentioned in SAL (#wikimedia-releng) [2024-01-17T12:25:51Z] <urbanecm> deployment-prep: foreachwiki userOptions.php --old-is-default --old=2 --new 1 --nowarn echo-subscriptions-web-reverted(T353225)

Change 987964 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: Enable conditional defaults for 4 Echo properties

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

I added user_properties rows for all users at the beta cluster. I also deleted the Echo user options for my testing user, and everything seems to work okay. Let's do the migration for all users and then we can go to prod.

Mentioned in SAL (#wikimedia-releng) [2024-01-18T11:54:28Z] <urbanecm> deployment-prep: mwscript userOptions.php --wiki=enwiki --delete --old '' --fromuserid=906 --nowarn 'echo-subscriptions-web-reverted' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:30:27Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=enwiki --delete --old 1 --fromuserid=906 --nowarn 'echo-subscriptions-web-article-linked' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:31:11Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=enwiki --delete --old 1 --fromuserid=906 --nowarn 'echo-subscriptions-email-mention' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:32:18Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=enwiki --delete --old 1 --fromuserid=906 --nowarn 'echo-subscriptions-email-article-linked' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:37:51Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=dewiki --delete --old 1 --fromuserid=52 --nowarn 'echo-subscriptions-web-article-linked' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:39:12Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=dewiki --delete --old 1 --fromuserid=52 --nowarn 'echo-subscriptions-email-mention' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:39:18Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=dewiki --delete --old 1 --fromuserid=52 --nowarn 'echo-subscriptions-email-article-linked' (T353225)

Mentioned in SAL (#wikimedia-releng) [2024-01-18T21:40:31Z] <urbanecm> deployment-prep: urbanecm@deployment-mwmaint02:~$ mwscript userOptions.php --wiki=dewiki --delete --old '' --fromuserid=52 --nowarn 'echo-subscriptions-web-reverted' (T353225)

@Ladsgroup: I'm now done with beta's enwiki and dewiki. I need to change userOptions.php to delete defaults without having to manually specify --fromuserid and/or --dry, since it is far too easy to make mistakes while running the scripts.

When measuring impact of my drops, please note that because of T355310: userOptions.php --delete --old '' deletes all rows, I managed to accidentally delete _all_ user_properties rows for echo-subscriptions-web-reverted in beta enwiki. The task is now resolved, but well, the issue already happened (thankfully, only in beta and not in prod).

Thanks. I have no concerns, just noting that there are two more left that are still used more 100K times:

MariaDB [enwiki]> select up_property, count(*) from user_properties group by up_property order by count(*) desc limit 5;
+--------------------------------------+----------+ 
| up_property                          | count(*) |
+--------------------------------------+----------+
| echo-subscriptions-email-page-review |   116706 |
| echo-subscriptions-email-edit-thank  |   116676 |
| popups                               |   105575 |
| rcenhancedfilters-seen-tour          |   105288 |
| wlenhancedfilters-seen-tour          |   105211 |
+--------------------------------------+----------+
5 rows in set (0.291 sec)

Ehh... Didn't know non-Echo extensions were setting Echo properties as well.

Dependencies for production deployment:

I'm at the Growth offsite next week, so let's do as much of the beta preparation as possible, and then we should be able to do it on first production wiki (very likely testwiki and/or test2wiki).

For deleting the rows from user_properties, I came up with the following script:

urbanecm@deployment-mwmaint02:~$ cat delete-user-property-rows.sh 
#!/bin/bash

WIKI="$1"

delete_rows() {
	TIMESTAMP='20130501000000'
	WIKI="$1"
	DEFAULT="$2"
	PROPERTY="$3"
	DIRECTION="$4"

	USER_ID=$(echo "select min(user_id) from user where user_registration > '$TIMESTAMP';" | sql "$WIKI" | sed 1d)

	echo "Deleting rows with $DEFAULT for $PROPERTY"
	mwscript userOptions.php --wiki="$WIKI" --delete --old "$DEFAULT"  --${DIRECTION}userid="$USER_ID" --nowarn "$PROPERTY"
}

delete_rows "$WIKI" 1 echo-subscriptions-web-article-linked from
delete_rows "$WIKI" 1 echo-subscriptions-email-article-linked from
delete_rows "$WIKI" 1 echo-subscriptions-email-mention from
delete_rows "$WIKI" '' echo-subscriptions-web-reverted from

delete_rows "$WIKI" '' echo-subscriptions-web-article-linked to
delete_rows "$WIKI" '' echo-subscriptions-email-article-linked to
delete_rows "$WIKI" '' echo-subscriptions-email-mention to
delete_rows "$WIKI" 1 echo-subscriptions-web-reverted to
urbanecm@deployment-mwmaint02:~$

For testing purposes four accounts have been created in testwiki. Find username:password below:

Registration happened before April 2013

  • TestEchoConditionalDefaults-checked:foobar1234
  • TestEchoConditionalDefaults-unchecked:foobar1234

Registration happened after April 2013, in 2024

  • TestEchoConditionalDefaults-checked-2024:foobar1234
  • TestEchoConditionalDefaults-unchecked-2024:foobar1234

The checked/unchecked suffix stands for the value the user properties should have in Special:Preferences#mw-prefsection-echo

Change 994732 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] testwiki: Temporarily change default value for 4 Echo properties

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

Change 994732 merged by jenkins-bot:

[operations/mediawiki-config@master] testwiki: Temporarily change default value for 4 Echo properties

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

Mentioned in SAL (#wikimedia-operations) [2024-01-31T13:48:04Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:994732|testwiki: Temporarily change default value for 4 Echo properties (T353225)]]

Mentioned in SAL (#wikimedia-operations) [2024-01-31T13:51:53Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:994732|testwiki: Temporarily change default value for 4 Echo properties (T353225)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-01-31T14:07:41Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:994732|testwiki: Temporarily change default value for 4 Echo properties (T353225)]] (duration: 19m 37s)

Mentioned in SAL (#wikimedia-operations) [2024-01-31T20:33:44Z] <urbanecm> [urbanecm@mwmaint2002 ~]$ mwscript userOptions.php --wiki=testwiki --old-is-default --old=2 --new 1 --nowarn 'echo-subscriptions-web-reverted' # T353225

Change 994857 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] testwiki: Enable conditional defaults for 4 Echo properties

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

Change 994857 merged by jenkins-bot:

[operations/mediawiki-config@master] testwiki: Enable conditional defaults for 4 Echo properties

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

Mentioned in SAL (#wikimedia-operations) [2024-02-01T00:12:13Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:994857|testwiki: Enable conditional defaults for 4 Echo properties (T353225)]]

Mentioned in SAL (#wikimedia-operations) [2024-02-01T00:13:45Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:994857|testwiki: Enable conditional defaults for 4 Echo properties (T353225)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-02-01T00:20:22Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:994857|testwiki: Enable conditional defaults for 4 Echo properties (T353225)]] (duration: 08m 09s)

Testing deployment plan at testwiki with echo-subscribtions-web-reverted

Before starting anything

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user where user_id not in (select up_user from user_properties where up_property='echo-subscriptions-web-reverted');                                                        
+----------+
| count(*) |
+----------+
|    54342 |
+----------+
1 row in set (0.049 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted';                                                                                                        
+----------+
| count(*) |
+----------+
|     4948 |
+----------+
1 row in set (0.004 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]>

Filling the database

[urbanecm@mwmaint2002 ~]$ mwscript userOptions.php --wiki=testwiki --old-is-default --old=2 --new 1 --nowarn 'echo-subscriptions-web-reverted'
[...]
[urbanecm@mwmaint2002 ~]$

After adding the rows

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user where user_id not in (select up_user from user_properties where up_property='echo-subscriptions-web-reverted');
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.066 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted';
+----------+
| count(*) |
+----------+
|    59292 |
+----------+
1 row in set (0.030 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]>

Deploying r994857

Standard scap backport 994857

Dry run (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/995028is sourcecode, with --dry used)

[urbanecm@mwmaint2002 /srv/mediawiki/php]$ time mwscript ../../../home/urbanecm/userOptions.php --wiki=testwiki --dry --delete-defaults  echo-subscriptions-web-reverted
[...]
Done! Would delete 27191 in total.

real    2m19.740s
user    0m45.240s
sys     0m5.414s
[urbanecm@mwmaint2002 /srv/mediawiki/php]$

Verification of the numbers

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted' and up_user in (select user_id from user where user_registration<'20130501000000') and up_value='1';
+----------+
| count(*) |
+----------+
|    22270 |
+----------+
1 row in set (0.338 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted' and up_user in (select user_id from user where user_registration>'20130501000000') and up_value='';
+----------+
| count(*) |
+----------+
|     2721 |
+----------+
1 row in set (0.177 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted' and up_user in (select user_id from user where user_registration>'20130501000000') and up_value='0';
+----------+
| count(*) |
+----------+
|     2200 |
+----------+
1 row in set (0.093 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select 22270 + 2721 + 2200 as sum;
+-------+
| sum   |
+-------+
| 27191 |
+-------+
1 row in set (0.000 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]>

27191 matches what the script reports, so everything seems to be in order.

Dropping the rows
Same as above, just w/o --dry.

Once finished

mysql:research@dbstore1007.eqiad.wmnet [testwiki]> select count(*) from user_properties where up_property='echo-subscriptions-web-reverted';
+----------+
| count(*) |
+----------+
|    32100 |
+----------+
1 row in set (0.019 sec)

mysql:research@dbstore1007.eqiad.wmnet [testwiki]>

This is...not what we wanted. 32100 is significantly more than 4948 (which is what we were starting with).

Investigating the problem

I spent some time thinking about what might be causing this abundance of rows. I figured that this happened, because the onLocalUserCreated rows only calls setOption() on newly created non-autocreated accounts. The deployment plan only results in removing rows when the new defaults configuration (with conditional defaults) covers more users than it used before, while ensuring existing accounts continue to have the same effective preferences. Since the majority of new accounts (especially at testwiki) are autocreated, executing the plan simply resulted in covering less users with the new defaults than before, resulting in (significantly more rows).

This problem has a couple of solutions:

  1. Create CUDCOND_AUTOCREATED and use it here: This will ensure all accounts will have the same preferences as before, and also ensure that the new default configuration will cover more users than before we started working on this. Unfortunately, detecting the autocreated status retrospectively is a significant challenge, especially from MediaWiki Core itself (it is not easy even from CentralAuth, but at least it can be determined with reasonable accuracy from centralauth.localuser.lu_attachment_method).
  2. Skip autocreated accounts when inserting rows: While filling user_properties to cover all users temporarily (so the default change can be done w/o actually affecting anyone), we can skip autocreated accounts. This will, however, flip the effective preference value for those users. For many (perhaps most) autocreated accounts, this is fine. However, this has still a great possibility of someone noticing & complaining, considering a significant portion of Wikimedia Commons / Wikidata users are likely to be autocreated (instead of registering at Commons or Wikidata). It might be reasonable to inform those users that their preferences might change for technical reasons and ask them to review & updated if necessary, but doing so would require CRS support (and a couple of weeks, at the very least).
  3. Stop inserting new rows now and delete pre-existing rows later: We can stop adding new rows fairly easily, the only thing we'd need to do is to instruct Echo to use conditional defaults starting today and remove the setOptions() call from the hook. This will stop filling the user_properties table with more and more rows, but it would keep the pre-existing rows in the database. Although I'm not a DB expert, this might be a good-enough solution for now. If at any point we feel the need to drop the rows, it can be done, likely by going through either 1 or 2 above.

For additional context: As far as I can see, the only way to determine autocreated-ness retrospectively (which is required for either 1 or 2), one would need to analyze the lu_attachment_method column of centralauth.localuser table, and map it to (likely) autocreatedness status (the map wouldn't be precise, since for example the admin method is used whenever someone connected the accounts manually, irrespective of autocreated-ness). Alternatively, one would need to analyze logging table and focus on the newusers logs. Both consist of analyzing existing data and drawing new conclusions, which is very likely to lead to unexpected errors, and missing the status for some users. This might not be a problem for 1/2, but it would still make writing the code for those solutions considerably more difficult.

Unfortunately, both the first and second solutions would require significant additional involvement from Growth (either myself or our CRS). This issue has already blocked me from focusing on Growth's annual priority for more than a month. Because of that, I'm unable to invest significantly more time to this task. As such, the Growth team would be willing to do no 3, but it currently lacks sufficient engineering capacity to complete either 1 or 2.

I'm convinced that even though Growth isn't able to meet the original target, introducing conditional defaults and stopping new rows from getting inserted can be considered sufficient for now.

I will take over the clean up, just please deploy the change ASAP so it stops adding more rows.

Change 999085 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] Echo: Use conditional defaults for 4 user properties

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

Change 999086 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/Echo@master] Stop inserting new user_properties rows on signup

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

Change 999085 merged by jenkins-bot:

[operations/mediawiki-config@master] Echo: Use conditional defaults for 4 user properties

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

Mentioned in SAL (#wikimedia-operations) [2024-02-08T21:37:03Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:999085|Echo: Use conditional defaults for 4 user properties (T353225)]]

Mentioned in SAL (#wikimedia-operations) [2024-02-08T21:38:30Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:999085|Echo: Use conditional defaults for 4 user properties (T353225)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-02-08T21:46:11Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:999085|Echo: Use conditional defaults for 4 user properties (T353225)]] (duration: 09m 07s)

Change 999089 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[operations/mediawiki-config@master] Echo: Conditional defaults: Fix start timestamp

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

Change 999089 merged by jenkins-bot:

[operations/mediawiki-config@master] Echo: Conditional defaults: Fix start timestamp

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

Mentioned in SAL (#wikimedia-operations) [2024-02-08T21:57:02Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:999089|Echo: Conditional defaults: Fix start timestamp (T353225)]]

Mentioned in SAL (#wikimedia-operations) [2024-02-08T21:58:28Z] <urbanecm@deploy2002> urbanecm: Backport for [[gerrit:999089|Echo: Conditional defaults: Fix start timestamp (T353225)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-02-08T22:06:31Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:999089|Echo: Conditional defaults: Fix start timestamp (T353225)]] (duration: 09m 29s)

I will take over the clean up, just please deploy the change ASAP so it stops adding more rows.

Done :).

Unfortunately, detecting the autocreated status retrospectively is a significant challenge, especially from MediaWiki Core itself (it is not easy even from CentralAuth, but at least it can be determined with reasonable accuracy from centralauth.localuser.lu_attachment_method).

We can check the oldest newusers log entry for the user and see if it's an autocreation or not. It's a range query on the log_actor_type_time index with a limit of 1, should be very efficient. There are some scenarios in which no log entry is created (e.g. autocreation by a global admin) but only for autocreation.
If we need to turn it into a batch operation some time in the future, that will be problematic, but that's already true for the registration date.

For User-notice: Since Feb 08, newly autocreated accounts (the accounts you get when you visit a new wiki) have the same notification preferences as users who freshly register on that wiki. This impacts the four notification types listed in the task's description.

Unfortunately, detecting the autocreated status retrospectively is a significant challenge, especially from MediaWiki Core itself (it is not easy even from CentralAuth, but at least it can be determined with reasonable accuracy from centralauth.localuser.lu_attachment_method).

We can check the oldest newusers log entry for the user and see if it's an autocreation or not. It's a range query on the log_actor_type_time index with a limit of 1, should be very efficient. There are some scenarios in which no log entry is created (e.g. autocreation by a global admin) but only for autocreation.
If we need to turn it into a batch operation some time in the future, that will be problematic, but that's already true for the registration date.

I looked and that could work, looking up logging table where log_title = user_name and log_type = 'newusers', if the log_action is 'autocreate' then it's auto-created.

A rather simpler approach is that we set the user_prefs for users who have these conditions:

  • Created after 2013
  • Their log action is 'create' and not autocreate
  • The user property is the old default or non-existent.

That'd give us a list of users to insert the rows. We insert those, change the default and then start dropping.

This works:

wikiadmin2023@10.192.48.205(fawiki)> select count(user_id) from user left join user_properties on up_user = user_id and up_property = 'echo-subscriptions-email-mention' where user_registration > '20130501000000' and (up_value is null or up_value = '0') and user_name in (select log_title from logging where log_type = 'newusers' and log_action = 'create');

We could take these and then feed it to userOptions.php via xargs.

e.g. in fawiki, it would add 18K rows and then we can drop 631K rows for each property.

For User-notice: Since Feb 08, newly autocreated accounts (the accounts you get when you visit a new wiki) have the same notification preferences as users who freshly register on that wiki. This impacts the four notification types listed in the task's description.

Hello @Urbanecm_WMF, is this ready to be captured in the next Tech News?

For User-notice: Since Feb 08, newly autocreated accounts (the accounts you get when you visit a new wiki) have the same notification preferences as users who freshly register on that wiki. This impacts the four notification types listed in the task's description.

Hello @Urbanecm_WMF, is this ready to be captured in the next Tech News?

Yes; this is an already deployed change. A database cleanup is in progress (T357072), but that will not be user-visible.

For User-notice: Since Feb 08, newly autocreated accounts (the accounts you get when you visit a new wiki) have the same notification preferences as users who freshly register on that wiki. This impacts the four notification types listed in the task's description.

Hello @Urbanecm_WMF, is this ready to be captured in the next Tech News?

Yes; this is an already deployed change. A database cleanup is in progress (T357072), but that will not be user-visible.

I have added this. Thanks!

Change 999086 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Stop inserting new user_properties rows on signup

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