The FAS group membership sync feature is requested to be configured for the following three GitLab subgroups of the main Fedora group:
council
diversity-team
mindshare
This is especially important for Council and Mindshare because the membership of this group changes routinely with Fedora elections. Members are added and removed consistently around the year. This manages better data access control to repositories tied to an active membership of these groups. Also, in these two groups, currently workflows require updating FAS group membership already, so it reduces work for maintainers during election administravia.
For DEI, membership is more consistent but it help me out a lot to be more efficient and timely with setting people up as we move to GitLab.
This would help Mindshare a lot as we are lagging behind on a migration, and our workflow is awkwardly split between Pagure and GitLab. This is also true to an extent with the other groups.
But there is no high urgency and criticality to this, so it should be prioritized with normal priority by the Infra Team.
What would you like those all mapped to? owner?
and just in case we haven't mentioned it to you before: If you enable group membership sync for a subgroup, gitlab will make sure ONLY those people in those exact groups have any access at all. ie, if you manually add someone via the admin interface, gitlab will remove them unless they are in the indicated group. Or if you adjust someones mapping (ie, make a developer a owner) gitlab will revert that. Just making sure you understand the implications.
Anyone who is a member of the mapped FAS group should have full owner rights in the GitLab subgroup. For now, we won't distinguish different tiers of access (although it would be nice if FAS group sponsors were GitLab subgroup owners and regular FAS group members were subgroup developers, without requiring two separate FAS groups).
I understand these implications. This was part of what made me confused about the Marketing Team at first, and was subsequently how I discovered this feature. It's handy for this use case. :smiley:
Anyone who is a member of the mapped FAS group should have full owner rights in the GitLab subgroup.
ok
For now, we won't distinguish different tiers of access (although it would be nice if FAS group sponsors were GitLab subgroup owners and regular FAS group members were subgroup developers, without requiring two separate FAS groups).
We cannot do this, gitlab only allows mapping a fas/saml2 group to a permssion level, nothing more or less. So, you could have 'foo-owners' fas group that maps to owners of foo, and 'foo-maintainers' that maps to maintainer level of foo, etc. Thats why I ask about this due to the multiple groups needed if you want to do different levels. ;)
Sounds good. Will try and get this done soonish.
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-trouble, medium-gain, ops
All 3 link should be setup now. Please let us know if there's anything further you need on it. :)
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Thank you @kevin! We will test and update if we have troubles.
Log in to comment on this ticket.