Add teams that represent a set of users

This feature has actually already been discussed in gitlab-foss#2772 (closed), but as teams and nested groups are not depending on each other, it seems more natural to discuss them in separate issues.

For me, a team is simply a set of users. These teams can then be given access rights to groups or projects just like single users.

If a user has been granted access to a group or project in multiple ways (one or more teams and possibly also as single user), the highest access level should be used.

Added feature proposal in GitLab FOSS label

cc: @dzaporozhets could you expand on why you dislike the concept of Teams?

I view them as not adding complexity to the hierarchy of the project, but rather as adding better organization to Groups. I really like the concept of being able to mention @gitlab-org/frontend rather than having to write out the usernames of every frontend engineer.

I also like the idea of being able to determine teams from within the GitLab application itself, e.g. if I were a new employee it'd become a lot easier to tell who I should talk to about Performance if there was a Performance team. Similar for Frontend, Design, DevOps, PeopleOps, etc.

This is probably best appreciated as a feature for installations that serve a fairly large company, e.g. Amazon, Google, Microsoft, Apple. Or even GitLab.com, since there are multiple organizations using this single installation.

@connorshea I don't like concept of teams because it brings extra level of complexity everywhere (from UI to backend) while benefits are questionable. Teams are necessary if you need to share same people with many projects. But we have Groups for this.

Marking certain people with certain specific (like you mentioned Performance or Frontend) can be implemented with flat membership structure just by tagging people with right things. I would rather see flat structure of group members with specific tags like frontend, backend, release manager near certain members.

I'm not sure if I got what you were suggesting @dzaporozhets. What I understood was that you would like to have tags that can be added to users. These tags can then be used to assign group permissions to each member with this tag.

If this is what you suggested, I don't see the difference to teams. Whether you have teams and allow users to be members of the team or whether you have tags that can be assigned to users is just another angle on the same thing.

My use case is the following: I'm using it at a University to manage several projects of different Student projects and institutes. There is one GitLab instance for the entire faculty. Some institutes at the university have multiple groups for different types of projects (i.e. Publications, Theses, Internal Reports, ...). Each new member of one of these institutes needs to be added to every single group manually and has to be removed when he/she leaves the institute. This process is very annoying and also quite error-prone.

Having nested groups as suggested in gitlab-foss#2772 (closed), would simplify our work a lot, but is no final solution. There are different types of members of an institute (academic employees, professors, students, ...). Depending on their type of association with the institute, they get different permissions to the available groups. A student, for example, would be in a student team and automatically be assigned Reporter permissions to the Theses group and Developer permissions for the Publications group.

Ditto what @Baertierchen said, I'm not sure I understand what the difference between the two proposed solutions are, other than in name.

I'm not sure I understand what the difference between the two proposed solutions are, other than in name.

@Baertierchen @connorshea the difference is:

• UI. People would expect Teams implemented like in GitHub or other pages with own page etc. My proposal is just extend members page with tags.
• General idea. Tags mean you can mark people with certain keyword. Team means you can add teams to projects, manage permission level for whole team, etc.

@dzaporozhets I really like the idea of using tags to group members together. On the other hand, granting permissions to a tag does not feel that intuitive to me. In case you do not allow to grant permissions based on tags, I don't see the big advantage of having them in the first place.

Which members page do you mean btw? I only know the Members pages of groups, but I don't see how you could add tags to every user from within these pages. Other than that, there is the Users page in the admin area, but obviously, only admins have access.

While writing this answer, I realised that there is another point that needs to be discussed: Which users should be allowed to create teams (or tag users) and who is allowed to change existing teams/tags?

Easiest solution: Only admins are allowed to do that.

Better solution (in my opinion): The creator of a team can define who else is able to manage team members.

Especially in the case of the second solution, I don't think tags work that well anymore.

@Baertierchen Originally idea of tagging was only for marking certain people with certain specific and for @gitlab-org/frontend mentions. It does not give any other functionality. Otherwise it would be confusing. Seems like you want different things like global team and permissions per team etc. Its different and tagging is useless for your case.

Here what you probably want and how it can be implemented:

• group people under certain specific and mention purposes => Tagging
• group people under one entity with same permission level within Group/Project => Teams in way like it implemented in GitHub.
• group people under one entity with same permission level separately from Group => No. Too much complexity -> more bugs and pain in development and usage. We had it in version 5 and removed it so I know what I talk about. Use Groups instead.

Well, what I would really need is your last bulletpoint, but seems this will not happen.

Maybe it is possible to grant permissions to projects/groups based on tags after all. This could also allow to define permissions based on multiple tags, i.e. Student and Development, which would be awesome 😉

mentioned in issue gitlab-foss#12736 (moved)

mentioned in issue gitlab-foss#17360 (closed)

mentioned in issue gitlab-foss#18017 (closed)

mentioned in issue gitlab-foss#2772 (closed)

(Jumping over based on gitlab-foss#2772 (closed) discussion.

Can I ask how my use case might fit in to the above proposed proposal?

I have projects with dozens of projects, and various groups of people that need some level of access to all of them. Currently, I need to add groups to each new project, or worse, when I have a new group of users, I have to go through each of the dozens of projects in various groups, and add it individually, at the correct level of permissions.

What I am looking for is being able to share all the projects in a group with another group, at some permission level. I had envisioned it as being able to share a group with a group, or allow groups to be assigned as members of another group, in exactly the same way as individual users are able to today. Either of these workflows would cut down on general gitlab administration considerably for me.

mentioned in issue gitlab-foss#17599 (closed)

@dzaporozhets I'm not sure I understand how Tags would be different from Teams? I imagine Teams as allowing you to be part of as many teams as you like, e.g. I'd be in Frontend, Performance, UX, Documentation, and Security. It's essentially the same feature but I think Teams is a better name for it.

I'm not sure I understand how Tags would be different from Teams?

@connorshea ah its simple: Tags don't need new UI views. You just render those on members page. You can name it whatever is better but idea is that we don't do any hierarchy in UI and we don't do Teams outside of Group scope.

we would like to have the following situation that kind of relates to this issue:

users groups of users (teams) repos groups of repos (projects) and we would like to be able to assign users and/or teams to any repo and/or projects.

thanks,

mentioned in issue gitlab-foss#19777 (closed)

mentioned in issue gitlab-foss#3804 (closed)

Just to share my use case...

I'm the CTO of a software consultancy, so we might have N clients with several projects per client. Over time we have a very large number of projects.

It seems logical that if there are several projects for one client they should go in their own group.

However now there's no way to manage things at the company level. For instance some people in the company should have access to everything, the graphics designers might get access to specific projects (e.g. those that are large enough to warrant design work) but don't want to be cluttered with everything else, a project or client might have a set of developers that need access managed together, and then some circumstances may warrant giving access to people outside the company.

I don't see how that can possibly be managed sanely through hierarchical groups, and anyway it's completely orthogonal to organizing the projects themselves, as explained above.

To me this use case screams "teams" but I'm happy to hear other suggestions.

Also I'm curious for more details on why teams didn't work out in version 5.

Thanks!

We now have subgroups, not sure if it fills 100% the "teams" feature. I wish we had the "teams" definition inside GitLab, as an easy way to mention team members, not really sure we should implement permission control on top of that (I can see the amount of pain).

Also want to note that a lot of people use GH Org with OAuth provider as a way to have simple centralized authentication to internal apps, with the team feature, you can do even more target restrictions like "only allow members of that Org that are also members of "Support Team".

moved from gitlab-foss#15234 (moved)