| bd808 | |
| Dec 19 2023, 9:11 PM |
| F43365499: Screenshot 2024-03-25 at 14.35.06.png | |
| Mar 25 2024, 8:36 PM |
| F41613755: Screen Shot 2023-12-19 at 2.10.35 PM.png | |
| Dec 19 2023, 9:11 PM |
When creating a gitlab account by authenticating for the first time the user is shown a banner about the pending account status, but that banner does not explain what to do next.
The text shown is:
"Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error."
Subsequent login attempts keep showing the user the same screen and banner until the account has been approved. The "New signins require approval; ..." banner defined in https://gitlab.wikimedia.org/admin/broadcast_messages is not seen even after account approval.
Thought: Maybe gitlab-account-approval could send a one-time message directing users to the form?
I finally did get shown the "New signins require approval; ..." banner when visiting https://gitlab.wikimedia.org/ with an existing session (no redirection through idp.wikimedia.org).
Hmmm... yeah we could try something like that. Tracking the "one time" state might be interesting. Maybe we could abuse the notes field in the user record for state tracking? An advantage of doing that kind of outreach with the approval bot is that we could set things up so the email is only sent to folks we cannot approve based on existing trust relationships.
I poked around a bit and I do not think we have any reliable way to change the "Your account is pending approval from ..." error message. There must be some configuration possible on that particular login screen however that makes the links to the ToU and CoC.
That was T285354: Sign-in text under Sign-in restrictions on https://gitlab.wikimedia.org/admin/application_settings/general
For posterity, the notice was moved to another config location with https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/53/diffs. The configured settings can be seen at https://gitlab.wikimedia.org/admin/application_settings/appearance, but should be updated via MR to the gitlab-settings automation repo so that they persist across automation runs.
I hate to be negative, but this does not feel ready for production. I have now been trying for over half an hour to figure out why I am getting this message and how to fix it. I've checked the documentation and have concluded that, since I am in trusted-contributors on Gerrit and in the LDAP group project-tools, I have to wait for the next time that this job runs to be approved — but it's not documented anywhere when that is!
Regarding my last comment, it was not ideal. I do believe that there is an issue here but I could've conveyed that in more considerate way. I am sorry for that and hope to see more work on this.
Kind regards from here.
@deni's problem turned out to be bad code in the bot. More info at T356350: https://gitlab.wikimedia.org/deni not being approved by bot.
In my experience, I was confirmed after a brief wait. It appears to be the sole process within the WMF ecosystem that requires approval, but I believe it's acceptable. From what I remember, the only prerequisite for potentially using this type of service is when you are creating an account to create your first Toolforge tool.
You were confirmed by the Tool-gitlab-account-approval bot because you were already a member of the Trusted-Contributors Phabricator group.
It appears to be the sole process within the WMF ecosystem that requires approval, but I believe it's acceptable.
There are a number of other systems which require some sort of human approval including some actions in Phabricator, Gerrit, and the Zuul/Jenkins CI system; Toolforge membership; Cloud VPS project membership; and many reporting/monitoring tools. These restrictions are largely necessary because these tools have limited tools for combating spam/abuse or they expose sensitive data to their users.
I understood it after being approved and finding the approval-bot repo, so adding details to the banner might be needed. Also, it took me months to understand that I could create a Wikimedia Developer (oh wait it's not only for the staff!) account with Bitu (and then in the end I think I created nothing but just linked IDM with my Wikitech account [LDAP] and my global account [SUL]).
There are a number of other systems which require some sort of human approval including some actions in Phabricator, Gerrit, and the Zuul/Jenkins CI system; Toolforge membership; Cloud VPS project membership; and many reporting/monitoring tools. These restrictions are largely necessary because these tools have limited tools for combating spam/abuse or they expose sensitive data to their users.
Yes, I wasn't complaining, it seems normal, but I'm using the Wikimedia Cloud Services for years now. For a new volunteer, all these processes might be still very complex to follow and understand. I wasn't speaking about CI/monitoring/reviews processes, but the delay before being able to use primary usages of the tools. Then again, not really a problem, but it's still a bit difficult to aggregate all these information.
Bitu (https://idm.wikimedia.org/) is simply a new system for creating a Developer account. A "Wikitech account" is a Developer account: T179461: Use the term "developer account" for Wikimedia LDAP accounts.
[20:28] < brennen> it'd be nice if there were a good way to signal "go get yourself in #trusted-contributors if you're not" when people try a login to gitlab. [20:28] < brennen> the banners aren't really cutting it. [20:29] < bd808> since folks can't see the banner until they have been approved... the banner is pretty useless. [20:30] < bd808> T353752 [20:30] < stashbot> T353752: Account pending approval banner shown on initial sign-in gives no context for how to proceed - https://phabricator.wikimedia.org/T353752 [20:31] < bd808> I'm not sure when things changed such that you couldn't get past the login screen without approval, but I'm pretty sure that is still the case today. [20:32] < brennen> i just switched to "show to all users on all pages", which may give some extra exposure. [20:32] < bd808> I could think more about the idea of having the account approval bot nudge folks too. [20:32] < brennen> i think it was pegged to / before, so maybe that's part of the issue. [20:34] < bd808> I can see the banner on https://gitlab.wikimedia.org/explore in an incognito session. Let's see what happens if I try to auth.
