How to make a project visible to everybody in an organization

I am new to GitLab and I am still trying to learn the right naming conventions.

My company is using and we are pretty happy with that. I guess my company is what GitLab calls a Group. We have multiple projects and sub-projects, each with one or more repositories.

I noticed that I need to get and give access to our repos on user basis, while it would be nice to get some default permissions because I am part of my company or of a specific team.

What I am looking for is:

  • A way to give access (maybe just as guest) to all my colleagues on my team’s repos
  • A way to allow everybody to be, by default, a guest in all repos (excluding some repos or some specific projects)

How can I achieve these two requirements with GitLab?

Thanks in advance.


Permissions in GitLab are inherited by sub-groups and projects, so one way to do it is to add everyone as Guest on your root group /something. This will give everyone Guest access, but you won’t be able to exclude specific projects.
I suggest to create dedicated sub-groups for specific teams as then you just need to add the user to the sub-group /something/marketing and user gets access to all sub-groups and projects within /something/marketing/*.
on you can also give permissions to groups/project to other groups. One way how to achieve what you need is to create what I call a user-group which won’t have any projects in it, just members assigned to it. You can add such groups (or any group really) as members of other groups and projects.

1 Like

Thanks for the quick reply. I guess what I am looking for is a user-group where to include all my colleagues and add that user-group as Guest to all sub-groups in my /something beside /something/very-private-stuff.

Will that work?

I’d suggest finding an organizational structure that allows you to assign roles and permissions on a (sub) group basis. The group permissions are then inherited to projects in the group. <--- Add all company members, default role is guest. 
  /group-frontend <--- frontend engineers as developers and/or maintainers
  /group-backend <--- backend engineers as developers and/or maintainers
    /group-backend-database <--- more granular scope for database planning
    /group-backend-api <--- focus on API development 

The structure also helps to organize epics on the group level, or group milestones to get a global or focussed overview on sprint planning.

For offboarding company members, remove them from the company namespace, and related groups.

If you are planning to add SSO and SAML group syncs at some later point, the group structure is already prepared too.

1 Like

Thanks @dnsmichi.

With your setup, if I want to have /group-frontend accessible only for the people in the frontend group, will that be possible?

My understanding is that being a guest in the allows to see everything.

That’s correct. My understanding was that everyone in the company should be able to at least see everything. This helps avoid silos between teams and also helps to e.g. report issues faster with direct access to issues and epics.

If you want to limit group access, the global COMPANY namespace should not have all team members as guest by default. I’m not sure if there is a possibility to block group inheritance from parent groups.