because of the way the gitlab SAML authentication works, there are some questions that we need to resolve on how to grant access to the Fedora Marketing GitLab subgroup (Fedora Marketing · GitLab)
Basically the background here is that if you enable SAML enforcing, only users that have authenticated with their Fedora Account can contribute to the repos. However the side effect that is undesirable is that the repos are then hidden unless you have logged in with your Fedora Account (i.e. Private unless logged in).
To work around this, the Fedora gitlab instance has disabled SAML enforcing – but this means that someone without a Fedora Account can be granted commit access. We can, however, then enforce SAML group links – which means that only someone in a Fedora Accounts group is given a certain role in gitlab.
You can go super granular, but will need a Fedora Accounts group for each gitlab role. Over on Fedora Websites and Apps, the plan is to map:
the websites-apps Fedora Accounts group to the developer role in gitlab
the websites-apps-admins Fedora Accounts group to the admin role in gitlab
Long story short, what groups in Fedora Marketing should we link to what roles in the Fedora Docs gitlab subgroup?
Right now there is only one FAS group for marketing. I think the easiest solution will be to make that FAS group the marketing-users and we should need to create the marketing-admin group to be mapped as developers.
I can facilitate getting the new marketing-admin group created (doing this for a few groups, so can get it done all at once )
who do you want as sponsors of the new Fedora Accounts group?
Also, Sorry for the churn here, but i was mistaken, there is no Admin role in gitlab, the main roles are:
Guest, Reporter, Developer, Maintainer, Owner.
We can keep the -admin naming for the Fedora Accounts group, and assign those members to the Maintainer roie. Changing the mapping between the group and role is easy, changing the Fedora Accounts group name is not – so want to make sure we have it right
You’re right. Reading that and taking into account that we manage 2 repos (docs and planning) and none of them are “code” (docs are code, but not code), it looks like reporter fits better for planning, but not for docs, and since having 3 roles seems excesive, I think we should go with developer as the “user role”.