 |  |
| | |
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
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.
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.
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 uses also the IM roster synchronization feature. Can be configured and the default does the synchronization
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.
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. Can be configured and the default does the synchronization
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.
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
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
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.
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
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.
| |  | |
 |