Translated using

Machine-translated page for increased accessibility for English questioners.

GitLab FI

Groups

The create custom groups feature is disabled in GitLab to prevent collisions with synchronized groups. If you need to create a custom group or want to enable group synchronization, contact an administrator.

GitLab will send you an email if you become a member of a group.

Synchronizing with faculty administration

This setting is useful for manually managed groups in faculty administration, such as research groups, faculty departments, or conferences.

When synchronization takes place

Synchronization of administrators and group members occurs hourly. For newly created accounts (after first logging into GitLab), partial synchronization starts immediately.

Member rights

For the Owner right, synchronization tries to be as consistent as possible with the faculty group settings:

If a faculty group has at least one administrator, then the Owner right is automatically kept consistent with the list of administrators. If someone grants Owner to other members, they will lose this right the next time they sync.
If the faculty group has no administrators, then the Owner right is not synchronized. An administrator can grant this right to other members as well.

The other members of the group will be given the default right when synchronizing (this can be specified when requesting synchronization settings). The group administrator can change this right in GitLab to any value other than Owner.

A non-personal Root account is also a member of such a group, so that when there are large changes in subject groups (usually between semesters), the group doesn't lose all its administrators. This account ignores notifications, so there is no point in tagging it.

Admin group

To better organize faculty groups, you can also request the creation of an administrator group, usually with the prefix adm_, which has the following properties:

adm_X can manage members of adm_X (i.e. itself): Administrators can grant administration rights to other members by adding them to the admin group.
adm_X administers group_X (or mail_X, ...): Administrators can add other members to administered groups.
adm_X is a subgroup of group_X (or mail_X, ...): Administrators can automatically be members of the group as well.
This setting is recommended but not required.

Request synchronization settings

Write to gitlabTtWV_f0Ew@fi_5jV3IShI.muniTPXWLE1b8.cz. Include at least the following information in the group creation request:

The name of the faculty group you want to synchronize. If we can set up a group, then include information about that group.
If the group does not have an administrator in the faculty administration, then provide the group's initial owner.
The default permissions that new members of the group will receive in GitLab. You can then change this permission for specific members in the group settings in GitLab.

Read the instructions for GitLab group administrators!

Synchronization with IS MU

Synchronization can also be set to synchronize groups in IS. Typically, it is used to synchronize the list of students or instructors of a course in the current semester with a group in GitLab.

Due to technical limitations, accounts cannot be synced directly from IS to GitLab, so faculty groups are used as an intermediate sync step:

Every two hours, instructors or students sync to a faculty group.
Every hour, group members sync to GitLab in the same way described above.

This section of the documentation therefore describes the synchronization options between IS and faculty groups. The synchronization of the faculty group with GitLab then follows the documentation above.

Manually adding members

Additional members can be added manually to synchronized faculty groups from IS. This is useful, e.g. for making GitLab materials available to external consultants, senior students, etc.

Beware, however, that these people will never be automatically removed from the group by synchronization with IS.

Configuring

Because you can sync students, instructors, and both from IS, you can also set up synchronization in different ways.

Student-only group

Suitable for allowing access to shared materials or for course projects.

For proper functioning, you need to designate an administrator in the group, which is usually the instructor or lab members. If you do not want to maintain the administrator manually, we recommend using the Group for Students and Instructors configuration.

Group for teachers only

In this configuration, the members of the group are lecturers only. You can optionally specify whether they should be lecturers, practitioners, helpers, or any combination of these subject roles.

Group administration can be granted for individual users or even another group. We can also set up an automatically synchronized administrator group for subject lecturers only.

Group for lecturers and students

This configuration is recommended for course synchronization where both lecturers and students want to have access to the same repositories, but generally with different permissions.

A minimum of three faculty groups are used for synchronization:

Administrator group. This usually contains all instructors. It can be divided into a group for lecturers and a group for others as needed.
The group for students.
A group that contains both of the previous ones. This is synchronized with the GitLab group for the course. The group for lecturers then has the right to manage this group, so they get Owner rights.

The advantage of this split is also the ability to set up additional synchronizations, e.g. for the teacher-only group.

Not sure which configuration to choose?

Email us at gitlabWhSyJO7fP@fi=-fAZxyMp.muniF7AtHrnhx.cz, how you want to use groups in GitLab, and we'll try to find a suitable setup.

Tips

We can set up an email alias for faculty groups on request.

Synchronization can also be set up for a subgroup in GitLab. For example, you can have a group where only faculty are members, and then a subgroup where students sync to. You can then move projects you want to make available to students between these groups.

If you are requesting a research group, consider having learners whose projects are important to your group. Such projects should then be moved to this group (Settings → General → Advanced → Transfer project) so that you don't lose them when the person graduates and have to deal with unnecessary complexity.

Request for synchronization settings

Write to gitlabQzvHw36j9@fixA8S2q=a8.munivw-3quldb.cz. In your request to create a group, please include at least the following information:

The course code or group name in IS MU that you want to synchronise.
If you want to synchronise lecturers as well, specify which roles the synchronisation applies to (lecturers, lecturers, assistants or a combination).
Specify the configuration you require or describe the rights each role should have.
Select the default permissions for each group that the configuration will require.

Read the instructions for GitLab group administrators!

Manually managed group

If you don't want to use synchronization, just ask to create an ordinary group in GitLab FI. The restrictions on granting rights for synchronized groups do not apply here, i.e. the administrator can give Owner rights to other members at will.

To request the creation of a group, please email gitlab-3uAAqp=c@fi=de94gU9M.muniUB5LU=NKU.cz, indicating the name of the group and the initial administrator.

Instructions for GitLab group administrators

If you have been granted the Owner right for a group, GitLab will allow you to change its settings.

You can change the Group Name.
You can change the description of the group (Description).
You can change the visibility of a group (Visibility) and the projects in it. When you set up synchronization, the group is always created with visibility Private.
When setting the visibility to Public or Internal, make sure to check the visibility settings of the projects first. This prevents unwanted publication of projects with sensitive data.
Never change the Path of a group without the knowledge and consent of the GitLab administrators!
Unfortunately, this option cannot be disabled in the settings.