Site-admins shouldn't be project admins for all projects
Summary
site admins seem to automatically be admins in each project (with full developer access).
This is rather awkward if your site admin is an active developer and you have a decentralized workflow where each project admin is supposed to manage their projects, including permissions.
Steps to reproduce
As site admin, go to any project: you can
- add members
- push to the repository
- ... (do anything)
There's also a few things you can not do, namely:
- request access to any project (to become a nominal member)
What is the expected correct behavior?
Now admittedly this is a bit tricky. A site admin can - by definition - do anything within the gitlab instance. It's also important that a site admin can troubleshoot any project, by setting permissions right, removing rogue members and so on.
However, it would be nice if those supercow powers could only be available when explicitly requesting them,
e.g. by turning on an "admin mode" (similar to the impersonate feature).
tbh, I cannot think of any use case where anybody including the site-admin needs to be able to push to a repository without being a member of the project (using their ordinary ssh-key that is not a deploy key with rw permissions).
As things are, the only way to avoid trampling on other people's repository (without taking excessive precautions), is by using separate accounts for your admin role and your developer role. This however, is in direct contradiction to (what seems to be the gitlab credo of) managing people rather than roles. It is also made rather complicated by GitLabs decision to disallow re-using the same email address for multiple accounts (just saying; i'm really trying to make a point for allowing a single user to act with different roles rather than forcing a human to juggle with multiple accounts).
Results of GitLab application Check
this is with GitLab Omnibus 10.2.4 (running on Debian/stretch)