Co-Maintainers Cannot Change Default Branch

@hestenet was able to resolve the immediate issue for me in the ifra Slack, but leaving this issue open for follow-up about what the expected behavior should be and whether it's working as expected.

Another team member has all maintainer permissions and is listed as "Maintainer" on the Gitlab members page. She also cannot access the Settings page.

If true that would imply a GitLab bug and I'm doubtful there is anything the Drupal Infra team could do with that. I would double check the user was logged into the correct account. In my experience it is very easy to be logged into D.O. but logged out of GitLab, especially if visiting with a direct link that doesn't trigger a re-auth through the SSO system.

Last I looked owners/full maintainers were given the GitLab "Maintainer" role and co-maintainers (not sure exact requirements but especially those without the "Administer Maintainers" permission) were given the GitLab "Developer" role.

The ability to modify the Default Branch is a GitLab Maintainer or Gitlab Owner permission. The maintainers role has capabilities that are equivalent to the D.O. "Administer Maintainers" permission.

It honestly makes sense in my mind that Gitlab consider changing the default branch a "maintainer" requirement as in most projects it fundamentally changes the future direction of a project by setting a new base that everyone should be working from, something a "developer" shouldn't be allowed to make the decision on.

I noticed this too: For projects where I do not have the Administer maintainerspermission, I cannot change the default branch. That permission is specific for adding maintainers/co-maintainers from the drupal.org side, and it should not be related to changing the default branch.

Yeah, that makes sense. I asked my coworker to double-check and ensure that they were logged in to Gitlab. They confirmed that they do in fact have the correct permissions while logged in on the Gitlab side. I wonder if there should be a note on the D.o administer maintainers page that clarifies that all (or which if not all) permissions must be granted to get the maintainer role applied in Gitlab.

On the other side, where I have been granted all the permissions on the project, I can see the Settings link and change the default branch.

That permission is specific for adding maintainers/co-maintainers from the drupal.org side, and it should not be related to changing the default branch.

GitLab has a set list of roles that can't be changed. There is no direct equivalent to the "Edit Project" role that previously allowed changing the default branch on D.O (though in theory it could always be added back in to the D.O. GUI.)

Based on #5 I'm re-titling this to the fact it only impacts co-maintainers.

This is a pretty minor issue IMHO, as long as a project as one active maintainer. We have been saying for a while as part of the project adoption that co-maintainers really should consider requesting an upgrade to full maintainer or owner if they are the only active developer remaining.

I know Gitlab has fixed roles; the "issue" here is that drupal.org permissions allow some operations on projects, but those operations are not allowed by Gitlab.
It will happen also when issues are moved to Gitlab issues: The Administer issues permission alone will not allow to make operations on issues because accounts with only that permission are given the developer Gitlab role.

It is not a matter of being the only active maintainer/co-maintainer on a project. It is having a drupal.org permission that allows some operations which are not then possible to do.

So some background first:
This issue was created by request on Slack because it was believed maintainer sync may not have been functioning, that doesn’t appear to be the case.

It will happen also when issues are moved to Gitlab issues: The Administer issues permission alone will not allow to make operations on issues

Since that isn’t a problem yet it is probably better discussed in #3250923: GitLab Collaboration Workflow: Enable GitLab issues and forking into the 'issue' namespace, with shared access across the community → or one of the other metas of converting to Gitlab. We don’t need to scope creep this issue.

It is having a drupal.org permission that allows some operations which are not then possible to do.

Technically nothing says any of the existing permissions control Gitlab permissions so this isn’t exactly true, arguably it’s the opposite issue, that permissions don’t fully describe the additional access they grant, which is also a different scope.

Technically nothing says any of the existing permissions control Gitlab permissions

Technically, project permissions are permissions that are also valid for the project repository; in fact, the Write to CVS allows to write to the project repository.

The current logic is https://git.drupalcode.org/project/drupalorg/-/blob/1430d1b1f7e935deb68f...

• If you have Drupal.org’s “write to vcs”, you have the GitLab “developer” role.
• If you also have Drupal.org’s “administer maintainers”, you also have the GitLab “maintainer” role. These are paired since GitLab project maintainers may also manage project members in GitLab.

There is not an effective way to control managing project members in GitLab. Drupal.org is not the single source of truth for project access. A GitLab project maintainer can grant that access to someone else within GitLab.

This will change a little in the future with #3262293: Grant GitLab “reporter” access to project maintainers with “edit project” or “maintain issues” → . And GitLab is starting to move on making more project roles possible https://gitlab.com/groups/gitlab-org/-/epics/4035

Everything is/was working as designed. The only thing I see to do here is improve the text on the Drupal project maintainers page.

I don’t see anything in the UI text on Drupal.org that’s inaccurate. Default branches are not mentioned. Since GitLab’s permissions will change as the GitLab product changes, I don’t want to get too specific about anything that’s doomed to become inaccurate.

We can update the blue help text at the top from:

Git access can also be managed on git.drupalcode.org.

To something like

GitLab access can also be managed on git.drupalcode.org.
“Write to VCS” grants the GitLab project developer role. Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role. Learn more about GitLab permissions and roles.

The new text should be sufficient to make clear to which Gitlab roles the drupal.org permissions correspond to.

The new help text has been deployed.

Automatically closed - issue fixed for 2 weeks with no activity.