Not every account has a "home" wiki

@Reedy Can you elaborate on that?

What we need to know is if an account was first created on the current wiki. (First created as in the user signed up on that wiki instead of visiting a random wiki while logged in)

I can do one better, I can give you an example. Though, it seems I might've over simplified the definition of "home" in my head :)

Compare https://en.wikipedia.org/wiki/Special:CentralAuth/Reedy (my "home wiki" is enwiki) with https://en.wikipedia.org/wiki/Special:CentralAuth/bd808 who seemingly has no home wiki as far as the CentralAuth gui is concerned

Maybe this logo is actually misleading in it's current usage... Home should be home, and we should have a different image for primary?

mysql:wikiadmin@db1079 [centralauth]> select gu_home_db from globaluser where gu_name = 'Bd808';
+------------+
| gu_home_db |
+------------+
| enwiki     |
+------------+
1 row in set (0.00 sec)

The globaluser.gu_home_db field doesn't seem to have been populated for all users though (there's a lot without it set)... Based on if ( $acc['attachedMethod'] == 'primary' || $acc['attachedMethod'] == 'new' ) it should've been filled in. There is a maintenance script (which I seemingly wrote... for this. I don't honestly remember if it was ever run, there's no task associated with it's creation.

I guess we should do that (will file a task)

mysql:wikiadmin@db1079 [centralauth]> select count(*) from globaluser where gu_home_db IS NULL OR gu_home_db = '';
+----------+
| count(*) |
+----------+
|  3501388 |
+----------+

CA considers "primary" to be home (as far as the images are concerned) when localuser.lu_attached_method = 'primary'.

Also, do remember, MW itself has no understanding of a "home wiki", that's in CA. CentralIdLookup has some awareness that there might be other wikis... But no understanding of a "home wiki"

52,762,465 global users.. only 15,044,487 have a lu_attached_method of primary, and 37,689,009 have new

Maybe we should expose the "home wiki" on Special:CentralAuth, like we do in the globaluserinfo api too...

"home wiki" is not a real concept. CentralAuth has the concept of home wiki purely for SUL migration. It is useless, and often wrong. You should not use it for anything.

The term HOME WIKI was loosely used as a way to label the wiki where the user created the account.

What we need is to determine if an account exists in a wiki because the user registered in said wiki vs an account that has been autocreated for them
Does anyone has a better idea on how to accomplish this in a reliable manner that is not querying the logging table like I suggested in the ticket description?

@Reedy The first thing I looked at was gu_home_db and a quick test revealed what you confirmed.
@Legoktm A bit off-topic. Shouldn't we either fix or remove gu_home_db? It has no value being there if the data is not valid(?)

I haven't read the full context of tickets, but why just not allow email on meta, a central wiki where everyone has an account? Saves people the trouble of trying to figure out which wiki a user is from, and then emailing them from there.

@Legoktm A bit off-topic. Shouldn't we either fix or remove gu_home_db? It has no value being there if the data is not valid(?)

Yes, probably.

Thanks, Lego.

Not a bad idea to lift this restriction entirely on Meta, if anywhere. But our primary concern for making this change is for Role Accounts on smaller wikis. We need a solutions where we don't have to identify each Role Account and reach out, which is why we believe "wiki where account was created" will suffice.

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu