-shell for the moment

It seems like it's a bug with CentralAuth for some reason

http://meta.wikimedia.org/w/index.php?title=Special:ListUsers&limit=500&username=Hos

Hosinheidari (Created on 4 November 2011 at 00:49)
Hosiryuhosi‏‎ (autopatroller) (Created on 14 January 2008 at 15:20)
HosiryuhosiBot (Created on 8 August 2009 at 15:52)

It's there in the list, so this isn't a major bug

It's Local User List(Special:ListUsers)...

(In reply to comment #3)

It's Local User List(Special:ListUsers)...

I've just found that when searching in Special:GlobalUsers it redirects your search to Special:ListUsers for no apparent reason, when this should not happen and never happened before. Maybe MW1.18 or recent changes in the Extension?

I'll fill a separate bug for this and link it to this bug.

Normal not-hidden users have gu_hidden='', and that's what is used to filter that list. However, both Hosiryuhosi and HosiryuhosiBot have gu_hidden = '0'. which is why they aren't shown by Special:GlobalUsers

gu_hidden was changed from a boolean to a varchar in r62827. Seems there are 678 which didn't get converted to '' afterwards.
Tim Starling, Lupo, Eloquence, Balderai, TheDJ, Emijrp, Magister...

The fix is just a matter of running
maintenance/runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"

quentinv57 wrote:

(In reply to comment #4)

(In reply to comment #3)

It's Local User List(Special:ListUsers)...

I've just found that when searching in Special:GlobalUsers it redirects your
search to Special:ListUsers for no apparent reason, when this should not happen
and never happened before. Maybe MW1.18 or recent changes in the Extension?

I'll fill a separate bug for this and link it to this bug.

I already reported this bug, please see #32278.

To me, this bug is not minor at all... some users exists and are not displayed on the user list. And this problem may hide some others with those accounts.

vigorous_action wrote:

Why isn't it processed?
Not being displayed on GlobalUsers is very inconvenient.
It desires to be improved immediately.

(updating blocker marked duplicate)

Deassigning as I'm not active on this ext and haven't picked up the bug myself.

Dropping priority since I didn't really provide a good reason for bumping up priority.

(In reply to comment #6)

gu_hidden was changed from a boolean to a varchar in r62827. Seems there are
678 which didn't get converted to '' afterwards.
Tim Starling, Lupo, Eloquence, Balderai, TheDJ, Emijrp, Magister...

The fix is just a matter of running
maintenance/runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser
SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"

All done now

quentinv57 wrote:

Reopening this bug.

MBisanz, one of our stewards, is not shown at [[Special:GlobalUsers]]. If this could be reviewed not only for this account but for every SUL account (already created or to be created), it would be appreciated.

Thanks.

Quentinv57

I see 75 users with gu_hidden='0' right now (including MBisanz).

Rerunning the command provided in comment 6 should fix it.

Registration date go from 20080325 to 20100311. They failed to convert in comment 12 run? Or is something placing 0s there?

For reference, the currently affected accounts are:
+---------+-----------------------------+-----------+

+---------+-----------------------------+-----------+

+---------+-----------------------------+-----------+

The command in comment 6 which was run by Reedy had LIMIT 50, which is probably why it didn't get all the bad accounts.

Bump. Shell users, can you consider running the command again, this time with a higher limit, please?

(In reply to comment #15)

The command in comment 6 which was run by Reedy had LIMIT 50, which is
probably
why it didn't get all the bad accounts.

Not really.

Considering this is now like, 10 months ago, I obviously cannot remember what I ran.

Have you actually looked at the maintenance script? It runs in batches. And while there are more than 0 rows affected, it goes and runs it again...

		$this->mDescription = "Run a query repeatedly until it affects 0 rows, and wait for slaves in between.\n" .
				"NOTE: You need to set a LIMIT clause yourself.";

reedy@fenari:/home/wikipedia/common$ mwscript runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"
Batch 1: 50 rows
Batch 2: 25 rows
Batch 3: 0 rows

However, I still see 35 users with gu_hidden = '0'.

mysql> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

+---------+------------------+

+---------+------------------+

Maybe the value is overwritten if they were using their account when the script ran? These entries refuse to be fixed... :S

(In reply to comment #19)

However, I still see 35 users with gu_hidden = '0'.

You listed 75, I fixed 75..

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

+---------+------------------+

+---------+------------------+
35 rows in set (1 min 35.67 sec)

mysql:wikiadmin@db1041 [centralauth]> ^CCtrl-C -- exit!
Aborted
reedy@fenari:~$ mwscript runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"
Batch 1: 35 rows
Batch 2: 0 rows
reedy@fenari:~$ sql centralauth
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 63981963
Server version: 5.1.53-wm-log (mysql-at-facebook-r3753)

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
Empty set (5.65 sec)

mysql:wikiadmin@db1041 [centralauth]> ^CCtrl-C -- exit!
Aborted
reedy@fenari:~$

Not a lot more I can do than that...

However, I still see 35 users with gu_hidden = '0'.

You listed 75, I fixed 75..

And 35 of them then returned to the wrong version.

Just as there are 18 back to '0' now:
mysql> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

+---------+------------------+

+---------+------------------+
18 rows in set (2 min 47.17 sec)

Yes, I know that it should have been fixed, and I don't understand either what's reverting them...

(In reply to comment #21)

Yes, I know that it should have been fixed, and I don't understand either
what's reverting them...

Are they in Memcached? Being loaded from their and then updated to the database when something else happens? Can we just hack in a conversion on load and wait a little while?

Gerrit change 46036

(In reply to comment #23)

Gerrit change #46036

As this patch was merged: Is it expected to fix the problem in this bug report completely?

The patches have been merged to cluster. It'll probably take a few days before it's fixed, depending on activity of those users.

Although I can fix it in the database (third time lucky), I think it makes more sense to let MediaWiki fix it itself. The bug might aswell stay open for now, and check on progress in a few days.

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
Empty set (2 min 12.78 sec)

Finally! :D