Steps to replicate the issue (include links if applicable):
What happens?:
'global_user_editcount' is returning 0. Meanwhile the local edit_count variable is functioning as it should.
What should have happened instead?:
The global_user_editcount variable should return the correct global edit count.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | BUG REPORT | None | T382292 'global_user_editcount' variable consistently returning 0 for the 'MediaWiki message delivery' account | ||
| Open | None | T111686 Attach existing system users to CentralAuth | |||
| Open | None | T275931 Have new system users be automatically attached to CentralAuth |
It is not saved
https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format#Variables_from_other_extensions
The variable itself works, on Special:AbuseFilter/examine
It seems to work when using the testing interface on Wikidata: https://www.wikidata.org/w/index.php?title=Special:AbuseFilter/examine/2357061929&testfilter=global_user_editcount. The code path executed should be the same. I am not quite sure what the problem is. Perhaps the context user is not set correctly during delivery? Or there is an issue with Meta-Wiki?
I don't think so. examine uses edits made, AbuseLog not if edit was blocked. See the warning on https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format#Variables_from_other_extensions - i think this is the problem.
I think the warning is a bit misleading because it does not concern only variables from extensions. I tried to explain this in T102944#8823633:
If no filter needs a particular variable to decide whether an action matches it, it will generally not be saved in the AbuseLog. (For global filters, it's somewhat complicated since we do an additional computation of some variables. This indeed does not concern extension variables since there is no way to enforce it.) I fail to find evidence of code setting any variables to false on purpose. Note that 0, false, null, and not set all evaluate to false, but they are different.
The fact that global_user_editcount is zero for a log entry, however, means that there was at least one filter that needed the variable, but it returned zero. Which is weird and I cannot explain it. Had anyone an idea, please speak.
The CentralAuth part seems fine - the editcount is tracked in the DB, the account is attached.
Possibly caused by T380500: CentralAuthUser returning outdated data after user creation? It seems like the only way for this to happen is for CentralAuthUser::exists() or CentralAuthUser::isAttached() to return false.
View this https://meta.wikimedia.org/wiki/Special:AbuseLog/3038654 log entry (requires private log viewing access on Metawiki)
exists() ought to be true. But isAttached() is actually going to be false!
The abuse log entry is from www.wikifunctions.org, and on that wiki, the 'MediaWiki message delivery' account is not attached to the global account. See for yourself that Wikifunctions is not listed here: https://meta.wikimedia.org/wiki/Special:CentralAuth/MediaWiki_message_delivery and just to double-check with the API: attached on Meta, not attached on Wikifunctions.
Someone helpfully created a user page that explains this: https://www.wikifunctions.org/wiki/User:MediaWiki_message_delivery which links to T275931: Have new system users be automatically attached to CentralAuth.
So that fully explains why this happens, and T380500 is not related after all.
But at least one thing is wrong here: there should be a section titled "List of local accounts" on Special:CentralAuth, but there isn't. Tracing through the code that displays it, it seems that the local user's existence is not recorded in the localnames table.