MW definitely thinks he's autoconfirmed

> $reedy = User::newFromName( 'Reedy' );
> var_dump( $reedy->getEffectiveGroups() );
array(5) {
  [0]=>
  string(11) "abusefilter"
  [1]=>
  string(5) "sysop"
  [2]=>
  string(1) "*"
  [3]=>
  string(4) "user"
  [4]=>
  string(13) "autoconfirmed"
}

> $user = User::newFromName( 'Bingobro' );

> var_dump( $user->getEffectiveGroups() );
array(4) {
  [0]=>
  string(9) "confirmed"
  [1]=>
  string(1) "*"
  [2]=>
  string(4) "user"
  [3]=>
  string(13) "autoconfirmed"
}

Certainly, the GUI reflects that as well. Short of asking him for his password what other options exist for troubleshooting this? Is there an "impersonate" feature that can be used by devs?

In T174282#3565524, @Xaosflux wrote:

Certainly, the GUI reflects that as well. Short of asking him for his password what other options exist for troubleshooting this? Is there an "impersonate" feature that can be used by devs?

We can of course change their password and test that way.

But no, we have no impersonate/sudo feature, beyond eval.php and reassigning $wgUser

How long has he been autoconfirmed now?

I expect he should have been since ~2017-06-02 (passing the 4day+10 edits threshold)

Xaosflux asked me to mention another account with a similar problem, User:Mountainsofpain.
https://en.wikipedia.org/wiki/User:Mountainsofpain

He registered in 2006 and has made 407 edits. On 19 October he said that his user page had disappeared, and shortly afterwards he found that he was no longer able to create an article. I added the confirmed user right, and he was able to do it again.

This problem has again come for Bingobro where Xtools showing the user is autoconfirmed but showing none in Wikidata User Rights.

This problem has again come for Bingobro where Xtools showing the user is autoconfirmed but showing none in Wikidata User Rights.

XTools uses looks at the registration date and edit count to determine when the user should have become autoconfirmed (since there is no entry in the user rights log for autoconfirmation). In this case XTools is wrong. Bingobro is not autoconfirmed on Wikidata, though they should be! Indeed this sounds like a bug in MediaWiki.

@MusikAnimal What was the method adopted to resolve this issue when it happened in enwiki?

In T174282#6261757, @Adithyak1997 wrote:

This problem has again come for Bingobro where Xtools showing the user is autoconfirmed but showing none in Wikidata User Rights.

This is a separate bug in XTools. Wikidata requires 50 edits for autoconfirmed (T48461) while XTools has no idea about that.

In T174282#6261763, @MusikAnimal wrote:

In this case XTools is wrong.

Probably Xtools should stop assuming 10edits/4days = autoconfirmed applies everywhere?

Bingobro is not autoconfirmed on Wikidata, though they should be! Indeed this sounds like a bug in MediaWiki.

He has made only 14 edits (as of writing this). In Wikidata, 50 edits are required before one gains autoconfirmed status. So there's no bug here.

Indeed, disregard T174282#6261763. It doesn't look like Bingobro is supposed to be autoconfirmed yet on Wikidata.

XTools scans https://noc.wikimedia.org/conf/InitialiseSettings.php.txt to get the configured wgAutoConfirmAge and wgAutoConfirmCount for a given wiki. I think the issue is that it's looking for the database name wikidatawiki, when here InitialiseSettings.php is using the alias wikidata. I have filed a bug at T256546 and will look into this soon.

Has this happened again since 2017? Otherwise inclined to close as "we'll never know what happened, no point investigating now
"