HelpFIT
Go to navigation

Groups

Groups organize users and projects and also serve as namespaces. Any project can belong to a group. All group members implicitly have access to projects within that group. The ability to modify or otherwise manage a project depends on individual permissions.

Only instructors and employees are allowed to create groups. Exceptions may be requested through the ICT department’s helpdesk. Groups can be nested within one another. Each group also receives a unique URL.

A typical example of a group is https://gitlab.fit.cvut.cz/BI-XYZ/B192, where:

  • BI-XYZ is the root group, in this case a course group.
  • B192 is a subgroup, in this case a semester group.

One particular use case for groups is the Course Groups concept.

Group Visibility

A group (and therefore its projects) can be assigned one of the following visibility levels:

  • Private – visible only to its members.
  • Internal – visible only to authenticated CTU users.
    • It will not be visible to authenticated users without a CTU account; see Sign In for details.
  • Public – visible to everyone without authentication.

Course Groups

Course groups are one of the practical uses of groups. The group name is derived from a shortened course code and is unique. Course variants such as BIK-XYZ, BIE-XYZ, and BI-XYZ.21 are normally merged into a single root group BI-XYZ.

They provide a convenient way to concentrate projects related to a particular course into a single group.[1]

Among other things, a course group contains the project for the Courses course website.

group detail en
Figure 1. Example of a course group for BI-PS2 containing projects for Courses pages (BIE-PS2 Materials and BI-PS2 Materials) and subgroups with projects for individual semesters.

Permissions

Unless specified otherwise for a particular project or subgroup, read access is granted to all authenticated users with a CTU account.

Like every group, a course group has members. These members are automatically synchronized according to their roles and relationship to the course in KOS. As a result, there is generally no need to manually add instructors.

Permissions within a course group are assigned according to the following mapping (KOS role → GitLab group role):

  • editor → owner
  • guarantor → owner
  • lecturer → maintainer
  • instructor → maintainer
  • examiner → developer

Members are added to the group during timetable preparation, before the semester begins.

Members are removed through expiration. Expiration occurs on the last day of the following semester.

Manual Adjustments

Group members with the Maintainer role or higher can modify the roles of other group members, change their expiration dates, or manually add members. These changes can be made in GitLab within the specific group on the Members page; see Members.

However, keep in mind that these parameters are periodically checked by an automated process. Under certain circumstances, manually modified values may be reset to their original state.

Examples of manual adjustments that require changing the expiration date include:

  • Reducing permissions — set the desired permission level and remove the expiration date (or set a later date).
  • Removing a member — set the permission level to Guest and remove the expiration date (or set a later date). Do not remove the member directly.

It is not necessary to change the expiration date for the following actions:

  • Increasing permissions
  • Adding a member

If needed, contact the ICT department’s helpdesk.

  1. Projects may originate from the course guarantor, lecturers, instructors, or, in some cases, students. ↩
  2. Any date later than the original expiration date, i.e., after the last day of the following semester. ↩