I'm using Gitlab 5.0 to manage my git repositories and I've never used github before Gitlab.
When I create a group, I see a new directory with this group name in /home/git/repositories.
But with team, no such thing is done.
Also, with group, I can create a project for the group and the assignments (for users of this group) is done automatically.
I can't see any other differences between group and team and I would like to understand that.
Thank you in advance and sorry for the bad English (I'm french),
GitLab 6.0 (August 2013, 22d)
See commit 3bc4845:
Feature: Replace teams with group membership
We introduce group membership in 6.0 as a replacement for teams.
The old combination of groups and teams was confusing for a lot of people.
And when the members of a team where changed, this wasn't reflected in the project permissions.
In GitLab 6.0 you will be able to add members to a group with a permission level for each member.
These group members will have access to the projects in that group.
Any changes to group members will immediately be reflected in the project permissions.
You can even have multiple owners for a group, greatly simplifying administration.
Why do references to Teams still exist in GitLab 7 then? e.g. "Filter by Team"
"Team" seems now (GitLab 6.x->7.x 2015) seems limited to a project (see for example features/project/team_management.feature, and app/models/project_team.rb or spec/models/project_team_spec.rb).
A project can be part of a group: see "Gitlab API for all projects under group".
"Group" references users, and can group multiple projects, (See features/groups.feature, app/models/group.rb, app/models/members/group_member.rb)
As a user, you are a first a member of a group, and have roles ('Reporter', 'Developer', ...) associated to a project (which makes you a member of that project, part of the "team" for that project).
No role, means "not a member of the team for a project".
See db/migrate/20140914145549_migrate_to_new_members_model.rb.
Answer for GitLab 5.x (before August 2013, 22d)
Group is for grouping projects, similar to a folder (git repositories)
Team is for grouping resources (people)
Those notions have been refined in GitLab 4.2.
That allows you to manage authorization in a more convenient way, given permissions to a group of projects in one operation, and/or given permission to a group of people, referenced by their team.
GitLab 5.x no longer used Gitolite, but before 5.0, teams and groups are coming from Gitolite, and its gitolite.conf configuration file.
This is where team and groups were declared and associated in order to grant permission access.
Even without gitolite, the idea persists: managing the authorization through association between teams (of people) and groups (of projects).
Related
I have a Azure DevOps Git repo on which two teams are currently working.
We created separate folders under 'feature/' for each team. Can we hide team1's feature folder from team-2?
Using git tf permission command, I was able to restrict the contributory access to other team's folders. But I just don't want the feature team folder visible to other team members.
Please click here to view my branch folder structure
As per the image, team-1 members should be able to see only 'feature/team-1/' branches. 'feature/team-2/' should not be visible to team-1 people.
It's NOT supported to hide specific branch for other team in Azure DevOps UI.
It's only supported to hide specific repo for one team, but cannot for branch level.
In Azure DevOps, a default project team will be created when we create a new project in a given collection. We can then add/invite members to this team and assign their level of permission. So far it is clear to me.
However, in my case, I have multiple projects and in each project there shall mostly be static set of developers.
Question:
a) Is it possible to create a default team at collection level (rather than project level) and assign users to it?
b) If srl (a) is possible, how would we instruct Azure DevOps to assign this default team as project team for all projects those shall be created under project collection ?
For example: Within a collection called Services, I have projects with users like below
Service A will have developers x, y
Service B will have developers x, y
Service C will have developers x, y, z
I prefer a default team with users (x, y); and this team will be assigned to all projects those are created under Services collection.
Exception: Service C has an extra developer Z. This is fine since we can visit project and explicitly add this developer.
a) Is it possible to create a default team at collection level (rather
than project level) and assign users to it?
No, it's impossible. In Azure DevOps, we provide collection-project-team structure.
Within a project, you can add teams
You could take a look at our official doc here-- About projects and scaling your organization and then decide if you need to create multiple projects or teams in your scenario.
As the above doc mentioned, we would suggest you handle a single project. Can a user account belong to more than one team?
Yes. When you add user accounts to a project, you can add them as members of the project, or you can add them to one or more teams added to the project.
Besides, you are also be able to structure hierarchical teams. Although there's no concept of subteams, you can create teams whose area paths are under another team, which effectively creates a hierarchy of teams. To learn more, see Add another team.
afaik it is not possible to create teams on collection level. you could, for example, create an Active Directory Group and use/reuse it in your projects.
We have a self-managed Gitlab instance of Community Edition. For security reasons, we want to limit some permissions like adding/removing project members. But it seems once a user becomes Owner, he/she has all the permissions that an Owner should have.
Is it possible to disable some of the permissions? Does the Enterprise Edition have this feature?
What are the best practices for accesses permission for programmers working in Azure DevOps? I would like the programmers to be able to use it, by for example having the possibility to create branches.
As far as I can understand by reading documents such as
https://learn.microsoft.com/en-us/azure/devops/organizations/security/set-git-tfvc-repository-permissions?view=azure-devops#git-repository
The only permission needed is a contributor? Is this correct or have I misunderstood the whole thing? The organization I’m working for have for example set the contributor to be a member of :
Build Administrators, Endpoint creators, Release Administrators
Creating users is different thing and assining rights is different thing. Your are looking for something named Policies.
Check for Branching policies in this case.
EDIT:
I was confused with the branching rights, however you can follow the Repository Permissions and Branch permissions to find how you can give permissions on your projects to users
You need to navigate to project settings and then to repositories. there you will find list of repositories and each repo can have certain rights assigned to it. some are inherited, some assigned. You can modify those to fit your likings.
this is the url: https://dev.azure.com/org_name/project_name/_settings/repositories
For more details, follow this link: https://learn.microsoft.com/en-us/azure/devops/organizations/security/set-git-tfvc-repository-permissions?view=azure-devops
thanks for you quick answer. Have digged into the documentation and repository permissions. I gave definitely som insight. My concern is that I want a predefined setting for managing the code repository on a team level, thus would no want to give project permission to the programmers. In my azure devops setup I have only on organization with hundreds of teams.
As I understand it, the permission for the repos are set at the project level. I would like to minimize the project level access since it gives to wide accesses in other cases and other teams. So my hope was that giving programmers contributor access would give the more or less all needed access for the repos out of the box. Such as:
1. Clone, fetch, contribute to pull requests, and explore the contents of a repository
2. Contribute to a repository, create branches, create tags, manage notes
Do not really understand why more access are needed. But could for example give the security control to the build admin role by granting the access to change permission. In this case the ones with build amdnin could adminitrate the security for its own team repos.
Any thoughs on this? Apologize if I have misunderstood you answer...
My manager asked me to create a resource work and project tracker in sharepoint or lightswitch. Is there any default template to do that... Basically I want to add up a team, resource, project, work items, approval flows in it.
Check out the Lightswitch Starter Kits, you could particularly use the Time Tracker kit to see projects, teams, and approval flows in action. Then extend it for your needs.