Page MenuHomePhabricator

Attach all broken autocreated local accounts to their global account
Closed, ResolvedPublic

Description

MetaWiki autocreated, detached accounts

See bug 29234, bug 35792, bug 39060, bug 39996, bug 39997 and friends for context.

One example silly query one can run e.g. on toolserver (sql metawiki_p):

SELECT

log_title,
log_user,
log_timestamp

FROM logging
JOIN user ON logging.log_action = 'autocreate' /*
AND log_timestamp > 20130431000000 */
AND logging.log_user = user.user_id
WHERE user.user_name NOT IN (

SELECT lu_name
FROM centralauth_p.localuser lu
WHERE lu.lu_wiki = 'metawiki'

);

15k results on Meta-Wiki only.

An actual query needs to be made slightly faster, I suppose, and actually check for the validity of the local account (it can be attached but nevertheless unusable, with password and email not working) and of its global username (which might have been deleted, or detached on purpose).

Note, at some point James said this would be done as part of the work for bug 35707.


Version: unspecified
Severity: normal

Attached:

Details

Reference
bz61876

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz61876.
Nemo_bis created this task.Feb 24 2014, 9:10 PM

Discussed with hoo and Nemo in #wikimedia-tech just now, if the user is unattached, has no edits, and has an empty user_password & user_email, we should be able to safely attach them.

If the user has a non-empty user_password or user_email, they should be able to either login or force a password reset.

(In reply to Kunal Mehta (Legoktm) from comment #1)

if the user is
unattached, has no edits, and has an empty user_password & user_email, we
should be able to safely attach them.

Right. So this is the very first thing to do even before bug 39817 comment 10 or all the rest gets too muddy. (Cf. https://www.mediawiki.org/wiki/Admin_tools_development/SUL_Audit/Metrics_20140704 .) Would be worth an "Highest", who wants to add this feature to the script(s)?

Change 144257 had a related patch set uploaded by Legoktm:
Add --attachbroken option to migrateAccount.php

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

I made a fork of sul-audit.py (source: https://gist.github.com/legoktm/85192e897d57c89aad56) to detect broken accounts, it's running on terbium right now.

Script took ~43m:

legoktm@terbium:~$ cat sul/broken-accounts.tsv | wc -l
18571

(In reply to Kunal Mehta (Legoktm) from comment #5)

legoktm@terbium:~$ cat sul/broken-accounts.tsv | wc -l
18571

For accounts with a user_editcount of 0:

legoktm@terbium:~/sul$ cat broken-no-ec.tsv | wc -l
18347

Change 144257 merged by jenkins-bot:
Add --attachbroken option to migrateAccount.php

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

2014-07-08 20:21:23 processed 18347 usernames (29.3/sec), 166 (0.9%) fully migrated, 17957 (97.9%) partially migrated

I'll look through the log to see why some accounts didn't get processed.

(In reply to Kunal Mehta (Legoktm) from comment #8)

2014-07-08 20:21:23 processed 18347 usernames (29.3/sec), 166 (0.9%) fully
migrated, 17957 (97.9%) partially migrated

I'll look through the log to see why some accounts didn't get processed.

I don't see any errors in the log. I think the count is off because some users had multiple unattached accounts, but as soon as the script processed the first of their usernames, it fixed all of them, so the later instances of those names were already "ok" and had nothing to do.

I'm going to mark this as fixed now. If the 224 users whose accounts we couldn't automatically re-attach would like their accounts back (and have a reasonable way to prove they owned it), I can take care of those manually (just file a bug and cc me). Otherwise they'll just be renamed out of the way during the finalization.

Ok, turns out this isn't fixed yet. There are about 1000 still broken accounts that the script could fix, but CA doesn't think they exist due to bug 67350.

2014-07-14 09:43:06 processed 1014 usernames (24.9/sec), 3 (0.3%) fully migrated, 1011 (99.7%) partially migrated

Running a script to verify there are no more of these left.

(In reply to Kunal Mehta (Legoktm) from comment #11)

2014-07-14 09:43:06 processed 1014 usernames (24.9/sec), 3 (0.3%) fully
migrated, 1011 (99.7%) partially migrated

Running a script to verify there are no more of these left.

Aargh. I ran migrateAccount.php --attachbroken using a list I generated 2 days ago. I re-generated the list, expecting it to be empty. There are now 7 usernames, all from commonswiki that are broken. They all have user_registration dates in the past 2 days, so it just means new broken accounts are being created.

(In reply to Kunal Mehta (Legoktm) from comment #12)

Aargh. I ran migrateAccount.php --attachbroken using a list I generated 2
days ago. I re-generated the list, expecting it to be empty. There are now 7
usernames, all from commonswiki that are broken. They all have
user_registration dates in the past 2 days, so it just means new broken
accounts are being created.

legoktm: Did you have some time to follow up on this? Is this still an existing problem, or has this been fully tackled?

The problem is that new broken accounts are still being created (bug 39996), so until that is fixed, we can't really fix all of them.

(In reply to Kunal Mehta (Legoktm) from comment #14)

The problem is that new broken accounts are still being created (bug 39996),
so until that is fixed, we can't really fix all of them.

Bug 39996 was closed, so the last maintenance script run should be the last!

List of broken users is generating now...

2014-10-15 21:02:37 processed 771 usernames (22.6/sec), 1 (0.1%) fully migrated, 770 (99.9%) partially migrated

Forgot to close this :)