You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@rahmatrhd and I tried generating the group access token for provider credentials in our personal gitlab groups/repo, but we couldn't find an UI based approach to do that (there's a way to get that done via console though but will be hectic for the end user). According to the documentation, the organisation hosted on the gitlab might have admin permissions to generate the group access token.
We are blocked on this provider in a similar way we were stuck in Github. The APIs to directly add a member to a group/project in Gitlab use the gitlab userID/username as parameter and not by the user email which we do in guardian. We tried a workaround to get the userID via /GET user API by passing public_email of user as the query parameter, but it is not necessary that every user might have made his email public. Therefore granting a direct access to a group/project which the user has requested for might not always work.
Proposed solution:
Maybe we can proceed with OAuth 2.0 for provider credentials, if we are looking to provide access to both groups of the organisation hosted in gitlab and general Gitlab groups and projects. If we only reduce the scope to the organisational hosted one, then group access token might work.
Similar to discussion in this issue Add support for Github provider #248, we can have the invitation based flow in Gitlab. The user will receive an invite to join the group/project via guardian when the appeal is approved. Once decoupled, the Appeal and Access will have the statuses to handle this kind of approval flow. @rahmatrhd@ravisuhag@AkarshSatija@bsushmith@singhvikash11
Summary
We need to support access management of Gitlab
Proposed solution
The text was updated successfully, but these errors were encountered: