Working with groups
This functionality is available in Self-hosted versions.
What is a group
A group is an entity for uniting users, projects, and subgroups.
Groups are used to organize work on related projects and to centrally manage access. When a user has access to a group, they can gain access to projects and subgroups within it, depending on the assigned role and access settings.
What are groups used for
Groups help structure the workspace and manage access to multiple projects from a single location.
Groups are used for the following tasks:
- combining projects of a single product or direction;
- separating projects by teams or areas of responsibility;
- managing user access to multiple projects;
- creating a hierarchy of groups and subgroups;
- viewing related projects and members in one section.
Hierarchy of groups and subgroups
Groups can be nested within each other. Such a structure allows separating projects and members by products, teams, components, or other work areas.
The following entities are used in the hierarchy:
| Entity | Description |
|---|---|
| Group | The main entity for combining projects, members, and subgroups |
| Parent group | The group within which another group is created |
| Subgroup | A group created within a parent group |
| Project | A repository or workspace located inside a group or subgroup |
Example of a hierarchy:
main_group
└── backend
└── module1
└── module2
└── frontend
└── landing
└── project-example
The maximum nesting depth for subgroups is 20 levels.
The main settings are located in the top-level group. When working with nested groups, it is necessary to consider that some parameters may be set at the parent group level and apply to entities lower in the hierarchy.
Access inheritance
Groups support access inheritance.
If a user or group gains access to a parent group, this access extends to all entities lower in the hierarchy:
- subgroups;
- projects inside the group;
- projects inside subgroups.
Example:
main_group
└── frontend
└── landing
└── project-example
If a user is added to the main_group, they gain access to the subgroups frontend and landing, as well as to the projects within them.
Not only the access itself is inherited, but also the assigned role. For example, if a user receives the Developer role in the parent group, this role applies to entities below, unless a different access rule is set for them.
On the access management page, the group through which the user gained access may be displayed.
Example:
| Field | Value |
|---|---|
| User | Gitflic User |
| Username | gitflicuser |
| Access obtained via | main_group |
| Role | Administrator |
Member roles in a group
The same roles are used for group members as for teams.
| Role | Purpose |
|---|---|
| Guest | Basic access to the group |
| Reporter | Extended access for viewing and participating in discussions |
| Developer | Access for working with projects and development |
| Administrator | Management of the group, members, and settings |
The exact set of available actions depends on the user's role and the settings of the specific group or project.
Group visibility and privacy
The visibility level can be configured for a group.
Two visibility levels are supported:
| Visibility | Description |
|---|---|
| Public | The group is visible to all service users |
| Private | The group is accessible only to users who have been granted access |
Access to a private group can be granted:
- by adding a user to the group;
- by adding a group;
- through role inheritance from a parent group.
When adding a user or group to a group, no invitation is sent. This differs from the invitation mechanism in teams and companies.
Group URL
The group URL is formed based on the group's path in the hierarchy.
If a group contains subgroups, the path of each subgroup is added to the URL after the parent group's path.
Example of a subgroup URL:
https://example.com/group/main_group/frontend/landing/-/overview
In this example:
| URL part | Description |
|---|---|
https://example.com |
Service address |
/group |
Groups section |
main_group |
Parent group |
frontend |
First-level subgroup |
landing |
Second-level subgroup |
/-/overview |
Group overview page |
The URL is used as the main user-facing address of the group.
Displaying the project owner during search
When searching for projects, the last group in the chain is displayed as the project owner.
Example:
main_group / frontend / landing / project-example
For the project project-example, the owner will be displayed as the group landing, since it is the last group in the hierarchy before the project.
Viewing a user's groups
A user can view the groups they belong to.
The list of groups displays groups where the user has:
- direct access;
- inherited access from a parent group;
- access via an added group.
To view a group:
- Go to the groups section.
- Find the desired group in the list.
- Open the group page.
After opening the group, a page with available sections is displayed. The set of available actions depends on the user's role.
Group page
The following sections are available on the group page:
| Section | Description |
|---|---|
| About the group | Basic information about the group |
| Subgroups | List of subgroups created within the group |
| Projects | List of projects associated with the group |
| Members | Users and groups that have been granted access |
| Settings | Group parameters, available to users with appropriate permissions |
The set of visible sections and actions depends on the user's role.
Group settings
The Settings section contains group parameters.
The following subsections are available in settings:
| Settings subsection | Description |
|---|---|
| General | Basic group parameters |
| Access management | Adding users and groups, configuring roles, and revoking access |
| CI/CD agents | CI/CD agent settings |
The main settings are located in the top-level group. If a group is part of a hierarchy, the settings of the parent group may affect nested subgroups and projects.
Managing access to a group
Access management is performed in the Settings → Access management section.
The following actions are available in the Access management section:
- adding a user;
- adding a group;
- selecting a role;
- viewing users with access to the group;
- viewing user roles;
- revoking access;
- removing a user from the group.
When adding a user or a group, no invitation is created. The user or group immediately receives access according to the selected role.
Adding a user
To grant access to a user:
- Open the group.
- Go to the Settings section.
- Open the Access management section.
- Select the Invite user action.
- In the User field, select the user.
- In the Select role field, select a role.
- Specify the access expiration date if required.
- Save the changes.
After adding, the user gains access to the group according to the selected role. No invitation is sent to the user.
Adding a group
To grant access to a group:
- Open the group.
- Go to the Settings section.
- Open the Access management section.
- Select the Invite group action.
- Select the group.
- In the Select role field, select a role.
- Specify the access expiration date if required.
- Save the changes.
After adding, members of the selected group gain access to the current group according to the assigned role. No invitation is sent to the group.
Access expiration date
When configuring access, you can specify the access end date and time in the format:
dd.mm.yyyy, --:--
If no expiration date is specified, access is valid without a set end date.
Viewing users with access to the group
The Access management section displays a list of users who have access to the group.
The number of users with access is also displayed.
Example:
Users with access to the group: 1
For each user, the following may be displayed:
| Field | Description |
|---|---|
| User | User's name |
| Username | User's login |
| Access obtained via | The group through which the user gained access |
| Role | The user's role in the group |
Example:
Gitflic User
gitflicuser
Access obtained via:
demo-group
Administrator
Revoking access
To revoke access:
- Open the group.
- Go to the Settings section.
- Open the Access management section.
- Find the user or group in the access list.
- Select the Revoke access action.
- Confirm the action if the system requests confirmation.
After revoking access, the user or group loses access to the group unless they have other direct or inherited access.
Removing a user from a group
To remove a user from a group, use the Remove from group action.
When removing, an additional setting may be available:
Remove direct membership of the user in subgroups and projects
This setting is used if you need to remove not only the user's membership in the current group but also their direct membership in associated subgroups and projects.
Limitations
- The groups functionality is only available in the self-hosted version.
- The maximum nesting depth for subgroups is 20 levels.
- Public and private groups are supported.
- The URL is used as the main user-facing address of the group.
- The main settings are located in the top-level group.
- Access and role are inherited by all entities lower in the hierarchy.
- When searching for projects, the last group in the chain is displayed as the owner.
- When adding a user or group, no invitation is created.
Automated translation!
This page has been automatically translated. The text may contain inaccuracies.