Allow creation access tokens on a group level or, how to merge users and groups
Project groups often have some common requirements. For one, we may want to have group-runners (which is happily satisfied of course).
Some projects may however need more. For example when doing cross-repo pull/push-ing or otherwise.
For example, if a release is tagged in one repo, we may want to create tag for each subcomponent (and thus push these).
To do these kinds, but probably many other tasks, the solution now is to create a personal access token, and set it in the group variables. But what happens if the user leaves the org? or deletes the access token and goes awol (or passes away).
Builds break, links die, project management is in pain.
An alternative option of course is to create a special user -bot or something, and make this user take on these tasks. But this user still needs to be created and maintained (password, e-mail) which is done by a person. Also failure prone.
Much nicer would be that a group would also contain a user. e.g. gitlab.com/user is also a group and vice versa. It would be a special user, in that it would have a limited number of parameters (visible I suspect), and any admin can change these parameters. As such, a password for the group is not applicable (an e-mail address of course could be a group e-mail address/mailing list.
This feature proposal comes close to what I suggested for [0] but is it's inverse. The discussion there was to be able to allow creation of subgroups under a user, but in effect, it's the same methodology.
For the future I would expect there be a button in the danger zone, 'convert user to organization' (and back to user) which would simply hide/show certain special features. Like passwords would be disabled for organizations, members are only valid for organizations etc.
While the impact on the current infra would probably great (I believe we have user and group namespaces) combining the two however makes sense ...
Links / references
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/39485#note_98254625