When a user created her account on ca.wikimedia.org, it did not create a SUL (the other way around works, i.e. when a user created an account on a Wikimedia account, it is created on ca.wikimedia.org). Accounts created on ca.wikimedia.org need to also create a SUL for all Wikimedia projects.
Description
Related Objects
Event Timeline
CentralAuth is enabled there. Are you the user just isn't automatically signed into their SUL account on other wikis?
I don't know if she is not able to log on other sites but when I look for User:Username on other sites it tells me this user is not registered.
@Amqui Could we meet on IRC the contributor, you and me? I'd like to perform a quick test and review the logs produced by this test, so we can isolate the issue.
I see the user on CentralAuth. The user in question is User:Syletourneau. I guess when a user creates an account on a given site, even tough SUL works for their login, if we search for this username on a site they never logged in we get the error message "User account "Syletourneau" is not registered.", although the user is technically "registered", she just never logged on that particular site. Is that the way it's supposed to be? If so, maybe the error message needs to be change. I believe if the user is registered within all SUL sites, no site should say that user is not registered.
No, accounts are created when visiting a site. Once the account is created, this message isn't shown, regardless of the edit count.
An account exists on meta.wikimedia.org and one also on mediawiki.org: https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php?username=Syletourneau
As you can see, https://meta.wikimedia.org/wiki/User:Syletourneau doesn't indicate the message.
I understand that. I think the confusion is just from the error message wording. It should at least say "is not a registered user on this site." It has been brought up to me by another contributor so I am not the only one thinking that.
So, from the Wikimedia configuration point of view, all works fine.
I analyzed the situation with @Amqui, and the issue is the wording of the userpage-userdoesnotexist-view message.
Message should be clarified, and ideally, a query to the CentralAuth database should occur to determine if a SUL account exists.
This is tracked as T152450.