Page MenuHomePhabricator

Attachment method should be preserved through global rename
Open, Needs TriagePublic


Global rename reads the attachment method (original home wiki, merged, autocreated etc) of each local account, then unattaches those accounts (thus erasing the status), and fires a "recursive" job that renames and reattaches one wiki, then creates a new version of itself for the next wiki. The original attachment method is passed along as an array of wiki => method from job to job.

This means that any job error causes the attachment method of the remaining wikis to be irretrievably lost, and the remaining wikis are listed as unattached. (They are not technically unattached, so nothing breaks, but it makes the UI confusing.) fixStuckGlobalRename.php tries to fix this by manually passing in a fake method but only does that for the one wiki it's called on so it doesn't really help. Besides, it's still a fake method.

As a quick fix, fixStuckGlobalRename.php should pass the fake method for all wikis. As a proper fix, the method should be stored somewhere safer (the renameuser_status table seems like a logical place). We should probably fix the incorrect "unattached" records for past renames, too.

Event Timeline

Tgr created this task.Mar 4 2018, 9:37 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Tgr renamed this task from Attachment status should be preserved through global rename to Attachment method should be preserved through global rename.Mar 4 2018, 9:38 PM
Tgr updated the task description. (Show Details)

Not sure if this is related. Note that each time we've used the --ignorestatus command, the unification dates displayed on CentralAuth break and instead of displaying the real date as per Special:Log@localwiki, they will display the dates in which the rename was performed instead. This should not be happening. T188721 (wikidata et seq. wikis display a wrong attachment date after the rename had to be unblocked using the ignorestatus arg.).

Tgr added a comment.Mar 5 2018, 11:30 AM

Same issue, yeah.

@Tgr Apparently this is caused without the --ignorestatus parameter lately as well. See T192476 and now. Attachments now appear as performed the day the rename was done. I know some voting/wiki scripts that actually check that data to determine elegibilities, etc. Thanks.

Change 493087 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/CentralAuth@master] Prevent fixStuckGlobalRename.php (somewhat) from breaking attachment data

Tgr updated the task description. (Show Details)Feb 26 2019, 7:51 PM

Change 493087 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Prevent fixStuckGlobalRename.php (somewhat) from breaking attachment data