Change #1251086 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Add maintenance script to backfill old interwiki rights changes

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

@mszwarc What happens if the old target user was renamed? For example, A09 granted adminship at zghwiki to Lhoussine AIT TAYFST, who was then renamed to Lhoussine Bentayfaste. As I understand the script, it would create a log entry for the non-existent Lhoussine AIT TAYFST rather than Lhoussine Bentayfaste.

Another case to watch out for is when the old username is then re-taken. For example, -revi was granted adminship on kowikiversity in 2022. In 2024, he was renamed to Revi C. He then created a new doppelganger account with the name -revi. It would be confusing to have a log entry that predates the target's registration.

For the record, there are 2134 entries of the first kind.

While this may be confusing, it reflects the current behavior for rights logs, which are neither carried to the new account on renaming.

@MGChecker That's not true. At the time of this log entry, the user now known as Veritas Sapientiae was named Hide on Rosé, and yet the log shows the current name rather than the old one.

In T6055#11703566, @NguoiDungKhongDinhDanh wrote:

@MGChecker That's not true. At the time of this log entry, the user now known as Veritas Sapientiae was named Hide on Rosé, and yet the log shows the current name rather than the old one.

That's a log entry for permissions on metawiki. Log entries for interwiki rights changes don't move when a user is renamed, see e.g. ~aanzx and their new user name A826. But I agree that the script would be confusing, because users currently don't expect misplaced log entries on local wikis...

That's a log entry for permissions on metawiki. Log entries for interwiki rights changes don't move when a user is renamed [...]

@Johannnes89 Yes, and that's exactly why I'm saying a naive algorithm wouldn't work. Local right changes have the type rights/rights, the same as the to-be-backfilled. These new entries would cause a mess, because there won't be any way to differentiate them. To go back to my second example, let's say -revi is renamed to -revi2. Would the old entry be retargeted as well? If yes, then I'm sure you too can envision what chaos ensues.

Currently, when a user right is changed from outside a wiki, the log entry appears the same as a local rights change. It would be helpful if there were an indicator showing that the change originated from outside the wiki.

For example, the following log entry appears in the local wiki:

12:29, 13 March 2026 MdsShakil talk contribs block changed group membership for YaThaWinTha: granted administrator (temporary, until 12:29, 13 September 2026) (per request)

Log link:
https://rki.wikipedia.org/w/index.php?title=%E1%80%A1%E1%80%91%E1%80%B0%E1%80%B8:Log&logid=4698

Another issue is that these duplicated log entries on local wikis appear to be hidden from Recent Changes.

As a possible solution, the log could include a source indicator similar to how it appears on Meta.

For example, the actor name could include the originating wiki in the format actor@sourcewiki when the log entry is duplicated on another wiki (e.g., MdsShakil@metawiki). This would make it clear that the action was performed externally.

Currently, on Meta the log appears like this:

05:59, 13 March 2026 MdsShakil changed group membership for YaThaWinTha@rkiwiki: granted administrator (temporary, until 05:59, 13 September 2026) (per request)

A similar format on the receiving wiki would help distinguish external actions from local ones.

In T6055#11705166, @MdsShakil wrote:

Another issue is that these duplicated log entries on local wikis appear to be hidden from Recent Changes.

Yes, currently it's unsupported to insert something into RecentChanges from remote context.

In T6055#11705169, @MdsShakil wrote:

As a possible solution, the log could include a source indicator similar to how it appears on Meta.

For example, the actor name could include the originating wiki in the format actor@sourcewiki when the log entry is duplicated on another wiki (e.g., MdsShakil@metawiki). This would make it clear that the action was performed externally.

Currently, on Meta the log appears like this:

05:59, 13 March 2026 MdsShakil changed group membership for YaThaWinTha@rkiwiki: granted administrator (temporary, until 05:59, 13 September 2026) (per request)

A similar format on the receiving wiki would help distinguish external actions from local ones.

MediaWiki already supports remote actors (eg. pl>Msz2001), but they are defined using an interwiki prefix and not database name – pl>Msz2001 is equivalent to [[pl:User:Msz2001]], whereas plwiki>Msz2001 is not linked (unrecognized prefix). However, interwiki prefixes are defined in a context of specific wiki (s: means something different on English and French Wikipedias), and it's currenty impossible to query interwikis on a remote wiki. Therefore the only alternative that I see is to render the interwiki log performers as metawiki>StewardName, which will be unclickable (metawiki is not a recognized interwiki prefix), unlike m>StewardName.

Or, maybe, metawiki should be then defined as an interwiki prefix for Meta?

MediaWiki already supports remote actors (eg. pl>Msz2001), but they are defined using an interwiki prefix and not database name – pl>Msz2001 is equivalent to [[pl:User:Msz2001]], whereas plwiki>Msz2001 is not linked (unrecognized prefix). However, interwiki prefixes are defined in a context of specific wiki (s: means something different on English and French Wikipedias), and it's currenty impossible to query interwikis on a remote wiki. Therefore the only alternative that I see is to render the interwiki log performers as metawiki>StewardName, which will be unclickable (metawiki is not a recognized interwiki prefix), unlike m>StewardName.

Or, maybe, metawiki should be then defined as an interwiki prefix for Meta?

metawiki could be added as an interwiki prefix. We already have meta defined as an interwiki prefix pointing to Meta-Wiki, so that could also be used.
I think this would be a better solution than the current approach.

In T6055#11705991, @MdsShakil wrote:

Or, maybe, metawiki should be then defined as an interwiki prefix for Meta?

metawiki could be added as an interwiki prefix. We already have meta defined as an interwiki prefix pointing to Meta-Wiki, so that could also be used.
I think this would be a better solution than the current approach.

metawiki would be useful, considering the recent RFC https://meta.wikimedia.org/wiki/Meta:Requests_for_comment/Change_our_sitename_value_from_Meta_to_Meta-Wiki

Change #1251294 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Always use external actor for interwiki rights logs on target wiki

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

In T6055#11703230, @NguoiDungKhongDinhDanh wrote:

@mszwarc What happens if the old target user was renamed? For example, A09 granted adminship at zghwiki to Lhoussine AIT TAYFST, who was then renamed to Lhoussine Bentayfaste. As I understand the script, it would create a log entry for the non-existent Lhoussine AIT TAYFST rather than Lhoussine Bentayfaste.

Another case to watch out for is when the old username is then re-taken. For example, -revi was granted adminship on kowikiversity in 2022. In 2024, he was renamed to Revi C. He then created a new doppelganger account with the name -revi. It would be confusing to have a log entry that predates the target's registration.

For the record, there are 2134 entries of the first kind.

I've found 5834 log entries (of both types) that affected users who were later renamed. I have an idea of how to implement that in the backfill script.

Change #1251294 merged by jenkins-bot:

[mediawiki/core@master] Always use external actor for interwiki rights logs on target wiki

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

Change #1253423 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@wmf/1.46.0-wmf.19] Always use external actor for interwiki rights logs on target wiki

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

Change #1253423 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.19] Always use external actor for interwiki rights logs on target wiki

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

Mentioned in SAL (#wikimedia-operations) [2026-03-16T13:29:42Z] <mszwarc@deploy2002> Started scap sync-world: Backport for [[gerrit:1253423|Always use external actor for interwiki rights logs on target wiki (T6055)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-16T13:31:27Z] <mszwarc@deploy2002> mszwarc: Backport for [[gerrit:1253423|Always use external actor for interwiki rights logs on target wiki (T6055)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-03-16T13:38:35Z] <mszwarc@deploy2002> Finished scap sync-world: Backport for [[gerrit:1253423|Always use external actor for interwiki rights logs on target wiki (T6055)]] (duration: 08m 53s)

In T6055#11706530, @mszwarc wrote:

I have an idea of how to implement that in the backfill script.

@mszwarc What is that idea like? A general description is fine.

In T6055#11715646, @NguoiDungKhongDinhDanh wrote:

In T6055#11706530, @mszwarc wrote:

I have an idea of how to implement that in the backfill script.

@mszwarc What is that idea like? A general description is fine.

It's in this patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1251086 and focuses on following the renameuser log on the target wiki (in batches so as to reduce the number of DB queries)

Change #1251086 merged by jenkins-bot:

[mediawiki/core@master] Add maintenance script to backfill old interwiki rights changes

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

Mentioned in SAL (#wikimedia-operations) [2026-04-08T12:15:16Z] <mszwarc@deploy1003> mwscript-k8s job started: foreachwikiindblist all backfillInterwikiRightsLog.php --remote-wiki metawiki 20260311190000 # T6055

As visible above, I have started to run the script on wikis. However, it stopped at Arabic, where some edge-case around following the rename log happened. I'll debug this and continue running on other wikis. Looking at logs, there are no broken entries inserted. Running the script again will not duplicate any entries that have already been inserted.

In T6055#11798864, @mszwarc wrote:

As visible above, I have started to run the script on wikis. However, it stopped at Arabic, where some edge-case around following the rename log happened. I'll debug this and continue running on other wikis. Looking at logs, there are no broken entries inserted. Running the script again will not duplicate any entries that have already been inserted.

Yes, a bug in the script caused it to go indefinitely on circular renames, if usernames contained a space (rename excerpt from arwikisource). I'll prepare a patch to fix it.

Change #1268971 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Change #1268971 merged by jenkins-bot:

[mediawiki/core@master] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Change #1269334 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@wmf/1.46.0-wmf.23] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Change #1269345 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@wmf/1.46.0-wmf.22] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Change #1269345 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.22] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Change #1269334 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.23] Fix BackfillInterwikiRightsLog wrt. cyclic renames

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

Mentioned in SAL (#wikimedia-operations) [2026-04-09T13:36:36Z] <hashar@deploy1003> Started scap sync-world: Backport for [[gerrit:1269351|fix: adjust to return type changed by upstream]], [[gerrit:1269339|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269340|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269345|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T6055)]], [[gerrit:1269334|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T6055

Mentioned in SAL (#wikimedia-operations) [2026-04-09T13:38:33Z] <hashar@deploy1003> mszwarc, hashar: Backport for [[gerrit:1269351|fix: adjust to return type changed by upstream]], [[gerrit:1269339|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269340|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269345|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T6055)]], [[gerrit:1269334|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T6055)]] sync

Mentioned in SAL (#wikimedia-operations) [2026-04-09T13:52:11Z] <hashar@deploy1003> Finished scap sync-world: Backport for [[gerrit:1269351|fix: adjust to return type changed by upstream]], [[gerrit:1269339|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269340|browser-tests: hide Cypress tests from CI (T419574)]], [[gerrit:1269345|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T6055)]], [[gerrit:1269334|Fix BackfillInterwikiRightsLog wrt. cyclic renames (T605

Mentioned in SAL (#wikimedia-operations) [2026-04-09T14:06:32Z] <mszwarc@deploy1003> mwscript-k8s job started: foreachwikiindblist all backfillInterwikiRightsLog.php --remote-wiki metawiki 20260311190000 # T6055 (second attempt)

The second attempt reached all way through enwiki, where it turned out that there's log entry with #41983@enwiki as target (I didn't know this is a thing, there are in total 11 such occurences for all wikis). I'll work to have it sorted out before continuing with backfilling the logs

In T6055#11804727, @mszwarc wrote:

The second attempt reached all way through enwiki, where it turned out that there's log entry with #41983@enwiki as target (I didn't know this is a thing, there are in total 11 such occurences for all wikis). I'll work to have it sorted out before continuing with backfilling the logs

I assume you've figured out that refers to the user ID numbers. I thought there'd be more than eleven, especially across all wikis,but there you go. Here's a bit on Meta about it: https://meta.wikimedia.org/wiki/Steward_handbook#Encoding_problems

The last time I'm aware of it being needed on enwiki was:https://en.wikipedia.org/wiki/Wikipedia:Bureaucrats%27_noticeboard/Archive_32#Inactive_admins_for_June_2015

Once this bug is resolved, I'll update this enwiki template accordingly:
https://en.wikipedia.org/wiki/Template:Former_admin_abbr

In T6055#11805947, @Graham87 wrote:

In T6055#11804727, @mszwarc wrote:

The second attempt reached all way through enwiki, where it turned out that there's log entry with #41983@enwiki as target (I didn't know this is a thing, there are in total 11 such occurences for all wikis). I'll work to have it sorted out before continuing with backfilling the logs

I assume you've figured out that refers to the user ID numbers. I thought there'd be more than eleven, especially across all wikis,but there you go. Here's a bit on Meta about it: https://meta.wikimedia.org/wiki/Steward_handbook#Encoding_problems

The last time I'm aware of it being needed on enwiki was:https://en.wikipedia.org/wiki/Wikipedia:Bureaucrats%27_noticeboard/Archive_32#Inactive_admins_for_June_2015

Once this bug is resolved, I'll update this enwiki template accordingly:
https://en.wikipedia.org/wiki/Template:Former_admin_abbr

Yes, I'm aware that this format is supported on Special:UserRights. What I meant is that I was sure that log entries would have an actual user name as target title (as in this log entry from 2015). Exposed unresolved id seems to have been probably a historical thing.

In T6055#11805952, @mszwarc wrote:

Yes, I'm aware that this format is supported on Special:UserRights. What I meant is that I was sure that log entries would have an actual user name as target title (as in this log entry from 2015). Exposed unresolved id seems to have been probably a historical thing.

Ah yes; that makes sense now.

Mentioned in SAL (#wikimedia-operations) [2026-04-14T13:55:08Z] <mszwarc@deploy1003> mwscript-k8s job started: foreachwikiindblist all backfillInterwikiRightsLog.php --remote-wiki metawiki 20260311190000 # T6055 (third attempt)