## 1.7. Groups

OLAT has a quite advanced group management system that can be used in courses to manage learning or right groups. In a special mode the groups can even be used withing several courses. The same course concept is also used completely independent of courses in so-called project goups. In this chapter you will learn how this all works

### 1.7.1. System roles versus resource owners versus business groups

First it is important to understand which groups we are talking about. There are several places in OLAT where you can add users to a group:

- System roles: The system administrator adds users to the system roles groups like 'authors' or 'administrators'. The system uses some `SecurityGroup` objects to store this information. The group membership is not directly visible to the members of this groups, they can't contact each other or something, they don't see who else is in the group. The idea is to manage rights (you can also say roles) on a system wide level.

- Resource owners: Whenever a resource is created someone must be responsible for this resource. Usually it is handy when this right can be shared by several people. The resource is then owned by a group of people. The most obvious place where this happens is in the learning resources repository. Creating a new learning resource, e.g. a course, creates also a `SecurityGroup` for this resource and adds automatically the creator of the resource to this group. Everybody in this group can now manage the resource, including the management of the owner group of this resource. Adding another user to the group makes the other user instantly to an equal owner of the resource. For example could the other user then remove the creator of the resource from the resource owners group and he would have no more access to the resource although he was the original creator. This is very much intended this way - try trusting your people :-). Compared to the system roles group the group is visible to the members, however the group offers no groupware features since the only purpose is to manage access rights. Other examples for such resource owner groups are the catalog entry owners or the groupmanagement owners (comprehensive group management).

- Business groups: Now whenever the group is the center of your actions, when the group itself is the main business case then we use so-called `BusinessGroup` . Business groups server the purpose doing something together as a group, maybe using groupware tools, maybe supervised by a coach. This groups have a name and a description and can be started in a runtime environment to work in the group. This is very different from the system roles or the resource owners group - those have no name and can't be started in a runtime environment since the purpose of those groups is only to manage access rights and not to communicate or collaborate with the members of the group.

In this chapter we talk about the generic business groups concept and where it is used within OLAT.

### 1.7.2. Generic business group and Grouptypes

The `BusinessGroup` class is a concept for a group that serves the purpose of collaborating, working or doing something together. The `BusinessGroup` is abstract in a way that it generically implements a set of functions that can be usefull when working in a group. However, in reality we deal with concrete groups that serve a special purpose and will use only a subset of all functions available in the generic `BusinessGroup`. To distinguish these concrete groups we give the `BusinessGroup` a field called `groupType` .

When thinking object oriented you could create an abstract superclass and use inheritance to create the concrete implementations. However, when persisting such a construct using a object-relational mapping layer like hibernate it can easily get complicated. Therefore we decided to make it differently and implemented one generic `BusinessGroup` together with one generic `BusinessGroupEditController` and one generic `BusinessGroupMainRunController` . The controllers offer the complete set of functions implemented by the generic `BusinessGroup`. When creating these controllers using the `BGControllerFactory` a configuration object `BGConfigFlags` is used to tell the controllers which functionality is enabled for the concrete group that is displayed or edited. This way the controllers must not know anything about group types, they only know which feature to display and which one to hide. Adding new features to groups or changeing features is only a matter of implementing the generic functionality in the businessgroup and the controllers and then enabling it in the configuration for all group types you want.

A `BusinessGroup` uses two `SecurityGroup` labled owners and participants. A `SecurityGroup` is a generic implementation of a group without any context or business meaning by itself. The meaning of those two underlying groups in the `BusinessGroup` class is that members of the owners security group have the right to modify / manage the business group wheras members of the participants security group do not have such a right.

#### 1.7.2.1. Learning groups

Learning groups are used in the course groupmanagement for

- Administrative purpose: Organizing students using the enrolment course building block or by adding them manually to the groups. Adding coaches to a group gives the coaches access to the administrative tools like the assessment tool for those users he is coaching. Note that without having your users organized in at least one learning group in the course you will not be able to see any course results for your participants since you just have no clue who is in your course anyway. Moste courses should have at least one learning group.

- Didactical purpose: Students should collaborate using the collaboration tools or the the author want to create a certain learning flow (also called learning experience) using accessability and visibility conditions on the course building blocks using the group membership constraints.

The distinction between those two is usually not so sharp and very often mixed. For both reasons you would create a learning group in a course.

Learning groups use the owner `SecurityGroup` for the coaches and the participants `SecurityGroup` for the students

Learning groups do not use the group rights feature but they use the area feature. More on this later.

Learning groups do not use the IM roster synchronization feature. More on this later

#### 1.7.2.2. Right groups

Right groups are used in the course to give some users certain administrative rights within the course. Usually you also want this users to be able to communicate together using a forum or to share documents.

Example 1: allow the professor to see and modify all assessment data but don't allow him to mess around in the course editor. In this case you would be in the owner group of the learning resource which makes you to the course administrator. The professor would not be in this group but you would create a new right group within the course and add the professor to this group. For this right group you would enable the assessment tool.

Example 2: you want all your coaches be able to manage all groups in the course. By default, coaches do not have full access to the groupmanagement and the assessment tool. The can launch the tools, but they have only access to the groups they are coaching. In some cases you want to give them access to all students, even to the one they don't coach. In this cenario you would create a right group and add all coaches as members to this group. Then you would enable the groupmanagement and the assessment tool for these group.

Right groups do not use the owner `SecurityGroup` at all. All users are members of participants `SecurityGroup`

Right groups use the group rights feature but they don't use the area feature.

Right groups do not use the IM roster synchronization feature.

#### 1.7.2.3. Buddy groups

Buddy groups (in the GUI they are called project groups, in the code they are named buddy group) are groups used for self organized learning or any kind of collaboration. They are created in the groups site by any user and managed by the participants of the group. There is no way to control such a group, therefore it shold not be used in the course context. The idea of buddy groups is that every user in OLAT can create his own peer network and collaborate or share for whatever purpose. This can be a semester work by three people, a discussion room for a clique of climber enthusiasts or a place where someone that is abroad for some month can post all the images to keep in touch with the friends stayed at home.

Buddy groups use the owner `SecurityGroup` for users that should be able to invite other users. Regular users are members of the participants `SecurityGroup`

Buddy groups do not use the group rights feature nor do they the area feature.

Buddy groups use the IM roster synchronization feature.

### 1.7.3. Groupcontext

Correlation between group context, groups, areas and courses

Every `BusinessGroup` has a reference to a `BGContext` and the `BGContext` has references to `OLATResource`. The idea of the business group context is to define the context in which the group is used.

Groups of type `BuddyGroup` are an exception since they have no dependecies to any OLATResource, thus they have not context defined (NULL)

The `BGContext` serves as a container for all groups that belong together. It has a type which means that a `BGContext` can only have groups of one type in it. `BGArea`, as we see later, do also belong to a `BGContext`.

Group contexts are used in course to manage groups. Every course has at least one group context for the type `LearningGroup` and one for the type `RightGroup`. When creating a new course a new learning and right group context is generated and labeled as a default context. A default context means that this context has been generated automatically for the purpose of the groupmanagement within this course. It is only good for this course.

In most situations this is fine and everything works as expected by using this default group contexts. But in some cases it makes sense to use the same groups in several courses. This is also called course comprehensive groupmanagement.

To achieve this it is possible to create `BGContext` that are not labled as default context. These group contexts are created manually in the groupmanagement site that is only available to users with the system role administrator or groupmanagement. Those `BGContext` do use a `SecurityGroup` to manage the owners of this context, to define who is allowed to manage this group context. To those contexts the owners can add one or more `OLATResource` (meaning courses) where this groups should be used.

Note that you can have more that one group context added to a course. When launching the groupmanagement in the course you then have to select which group context you want to manipulate. Everyone who has access to the groupmanagement within a course can modify the groups as if it where a default group context containing course internal groups. They do not need to be in the contexts owner security group.

### 1.7.4. Areas

A `BGContext` can have so-called `BGArea` relations. An area has a name and description and is used to associate many groups to a certain area of a course. In the GUI we call it learning area.

You can see areas as a group of groups, however a group can be in more than one areas, thus it is not really a group of groups. You could also see an area as a group attribute, a tag that you stick on a group.

From a paedagogical perspective it makes sense to ask “are you in group red, blue or green”, then do something. However, this gets very complicated with may groups. It would be much easier to ask “are you in a color area” and then add all your groups to this color area. This is what the `BGArea` is good for: address and organize groups that fullfill the same purpose.

Example: create an are enrollment and add your groups Class Monday, Class Friday to this area. In the enroment course building block use the area instead of the group names to define which groups can be used for enrolment. OLAT automatically offers the user all groups of the defined learning area to enroll into.

You can also use the areas to define learning activities and associate groups to this activities. In the course building blocks you then restrict access and visibility of certain blocks to groups that participate in the named activity.

Areas are only used by business groups of type `LearningGroup`

### 1.7.5. Rights

Group rights can be associated to a `BusinessGroup`. All possible rights are defined in `CourseRights`, a right is nothing more than a string that has a business meaning. Using the `BGRightManager` it is possible to ask OLAT wheather a user has a certain right in a certain group contex.

Currently group rights are used in course right groups to grant full access to the course editor, the assessment tool, the groupmanagement or the archive tool.

Rights are only used by business groups of type `RightGroup`

### 1.7.6. Group type based localization

Since the whole `BusinessGroup` codebase is completely contextless implemented and uses the same code for buddy, learn and right groups a special issue must be covered and this is localization. On screen the generic code must have group type dependent locales. In some locale strings only the group type differs, in others it makes sense to have different sentences like when sending mails after beeing added by someone in a group

To solve the problem of one generic code and multiple translations depending on the type we use the translator fallback mechanism. Each `Translator` can have its fallback translator in case the key is not found. This way it is possible to build a chain of translators. The GUI controllers of the group package use the `BGTranslatorFactory` to generate a package translator that use a group type translator in the first position of the translator chain.

In the package `org/olat/group/ui/run` a certain key is used to display someting in a group, e.g. a title. As soon as you define the same key in the package `org/olat/group/ui/buddygroup` or `org/olat/group/ui/learninggroup` the key from the group type specific package has precedence and is used for translation.

### 1.7.7. Collaboration tools

Each `BusinessGroup` has `CollaborationTools` that are used in the groups run time environment to communicate and share data. The collaboration tools are generated using the `CollaborationToolsFactory` and are not group type specific.

The group owners or administrators can enable and disable the collaboration tools in the edit mode of the group on a group level.

Currently we have the following tools available:

- Forum for group discussions. The forum supports notification subscriptions about modifications using email and RSS.

- Folder for file sharing. The folders are mounted as group folder in the personal WebDAV folder that can be mounted like a local folder on your desktop and allows manipulating the files using drag and drop. The folder supports notification subscriptions about modifications using email and RSS.

- Chat for synchronous discussions. This is only available when the Instant messaging module is enabled.

- Contact form to contact all group members

- Info message to display a welcome or info message that is shown when starting the group in the runtime environment.

- Members list shows the list of members.

- Wiki a Wiki used only in the group context

### 1.7.8. IM roster synchronization

The `BusinessGroup` allows synchronization of group members with your Instant Messaging roster list. This features is only available when the Instant messaging module is enabled.

Synchronized groups appear in the top navigation night next to the IM status. In brackets two figures are show: number of online buddies and number of total buddies. Buddies in this terminology are users that are in a buddygroup that you participate.

IM roster synchronization is only enabled for business groups of type `BuddyGroup` and can not be configured.