This seems like a fine idea.

I think there are 2 variations that we would ideally handle here:

• User has been created in GitLab via authn but is still pending admin approval
• User has not yet been created in GitLab

For users that need approval, the /users API response for that user will contain 'state': 'blocked_pending_approval'. Granting approval can be done via the POST /users/:id/approve endpoint.

When the user is still pending creation Striker sends them an invitation to join the project that is being created. There is no obvious way to pre-approve the user via the invite API. Something like T317376: Update GitLab repo owners when tool maintainers change could re-check for users in 'blocked_pending_approval' state and then make the approvals. That will probably be pretty hidden and magic from the POV of the users however. Maybe it could be made less surprising with some info on the repo detail screen? Checking and possibly updating status on load of that screen would also seem reasonable to make state reconciliation easier to reason about.

bd808 opened https://gitlab.wikimedia.org/toolforge-repos/gitlab-account-approval/-/merge_requests/1

Do the needful to approve GitLab accounts of folks who are already considered trusted contributors in other Wikimedia systems

The new Tool-gitlab-account-approval tool is now patrolling for unapproved accounts every 3 minutes and marking them as approved if it can find signs of trust for the related Developer account in multiple systems (Phabricator, Gerrit, Toolforge, ...). This is probably "good enough" for extending trust to newly created accounts.