This feature would really be usefull for a lot of people, see :
http://moodle.org/mod/forum/discuss.php?d=43755

Would be very cool to have it in 1.9.1.

anything that goes across courses brings trouble, this is definitely not easy to solve

That would be very usefull !

Why not enhance the meta-course enrollement sync capabilities in 1.9 ?
When adding a new descending course, a new grouping may be created with the same name, and groups (from the descending course) synchronized into it. Darren Smith already proposed a patch to synchronize simple groups in that same discussion. Maybe that's a place to start ?

well the metacourse itself is not working very well,
I agree this should definitely be fixed in 2.0

there were discussed several ideas how to do this, but there is no patch yet

One of the biggest barriers to institutional use of Moodle in schools, I think, and one that makes competitors look good. With this fixed, the burden of maintaining class lists and enrolments goes from the individual teachers to the admin staff where it belongs. 1.9.1 gets my vote, if its at all possible.

Petr, i understand it's not easy to put in, but i think it's a really important missing feature in Moodle, that should be in Moodle 2.0 roadmap ! Of course, better if fixed in 1.9.x

In fact, i really think that we should be able to define groups at several contexte in Moodle, as we can give roles at several contexte.

It would be good to have groups (and groupings) at these levels :

• system
• cours category
• cours sub-category
• course
• activity (perhaps)

and capabilities allowing you to define/use groups of the different categories, and you could use groups defined at a higher level.

Another very good thing would be to give roles to groups (or groupings) of users for a contexte

With the responsibility of folling this out over a school of 1500 students and 250 teachers, it is the single biggest obstacle to teacher uptake. It would make a massive difference in the adoption of Moodle if unnecessary administration tasks are eliminated.

We have a real need for site level groups, for example '"Campus". We have pre-defined them for each course, but if we had to set up a course for everyone in the Campus, we would have to re-assign each student to a group. Could the "group" be an attribute of either a student or of a course?

We've got over 10,000 employees needing access to a whole raft of courses and each employee needs to be in a groups so that their learning can be tracked for their and the organisation's development. This would make my job a whole lt easier as i administer the whole lot on my own at the moment.

Having site wide Groups will massively reduce replication each time a course is created and also reduce confusion for Course Creators.

Having this ability should also then provide the options to allow Groups to only view their own content.

My site has users and students from North America down to ChiIe, South America. It would be very helpfull to be able to create groups by country or region. I vote for global groups!

I just noticed from here:

http://tracker.moodle.org/browse/MDL?report=com.atlassian.jira.plugin.system.project:popularissues-panel

that this issue is the the most popular one by votes which has not yet been assigned a fix version. Is it possible for 2.0? I'd love to be able to start experimenting with the (hopefully) 2.0 student information API to get our school classes defined at site level based on data from SIMS. (see here: http://docs.moodle.org/en/Student_Information_API )

Hello,
I agree this feature must be part of 2.0

this is a very important requirement for the University of Canberra's new implementation. We'd love to see it as soon as possible. It will greatly assist the extension of Moodle beyond 'courses', towards communities of learnesr/scholars.

I've started a discussion about this feature in the developper forum :
http://moodle.org/mod/forum/discuss.php?d=100421

Groups are just a way of classifying things. You need a different type of group for each type of thing. Ideally, we should be able to create user groups, course groups, role groups, etc. I'm not suggesting that we actually do this, but I think it is the right way to think about groups. From now on when I say "groups" I mean USER groups.

Groups should be hierarchical, i.e., divisible into sub-groups, ad infinitem. The hierarchy should not be single rooted, allowing users to simultaneously belong to multiple groups.

Groups should be permissionable. The semantics of assigning a role to a group should be the same as assigning the role to all of its members. This would make it easier to use role assignment (a strategic solution) instead of override (a tactical solution) in many important use cases.

Currently, the lack of groups above course level is leading to the misues of roles to classify users. Two examples: (1) the Keyholder role and (2) the filter criteria in bulk user actions.

Hands down the most important missing feature in Moodle. We have endless discussions with teachers about why they have to set up the same class over and over. Please please please make this one a priority !

Site wide groups in moodle

As this is a most wanted feature, we developed a integration strategy, in order to fit it to the needs of most teachers and users of moodle. So interested about your feedback and if it is possible to integrate this function as described below.
Aim:

as user friendly as possible and as easy as possible to integrate to actual system
Principal functions of site wide groups.

1.

every user can be part of several different groups
2.

no groups in groups allowed (at this point, could be changed in later versions)
3.

a group should be treated like a single user: enrol groups or users in courses, change roles for a group, etc.
4. course groups remain unchanged (see chapter "How to combine course groups with site wide groups")

How to manage site wide groups?

1.

In the user admin section there should be a container called ?groups"
2.

In the user admin section you can create site wide groups
3.

In the group properties the admin can define how to subscribe to a site wide group. To choose frome following options:
*

Subscribe with a key: When registering, or later on in the user profile you can enter a key and then subscribe to a group by entering the key defined in this section.
*

Subscription only by site admins: Only site admins can add user to this specific group
*

Allow some users to change this group: (select user from list or an existing group)
*

Open group: Everyone can choose to be in that group or not

4.

there should be a default group, all users are subscribed to if no site wide groups are created
5.

when user is registering on the site, in site admin there should be a Option ?Register only with key".
6.

In bulk user action: you should be able to delete groups

How to combine site wide groups with course groups?

In the course preferences there should be two options to choose:

*

Use site wide groups also as course groups (when groupe mode is on)
*

Define separate course groups (for example two site wide groups are enrolled into the course, but a need to have smaller course groups, so I can define my own course groups)

Roles and site wide groups?

*

As users you should be able to define roles for groups for several levels:
o

site wide
o

course categories
o

activities (depending whicht option under ?How to combine site wide groups with course groups?) is chosen.

Further comments

Feedback from programmers point of view would be greatly appreciated.

Yours,

David

Hello,

It looks like there are two kinds of building groups in moodle: groups and roles. Roles to me look like functional groups, dealing with privileges and access. Groups look like logical groups, dealing with chopping up course participants into slices (not to be taken literally...).
In a company, there are logical groups like technical service personnel or development staff which are all very much like students, but stay the same in a site wide manner.
Thinking about logical and functional groups like described here might help in finding the right implementation and might give hints to how to get a reasonable hierarchy for structuring groups.
To me sub-groups seem to be important as in a logical group like the technical service personnel there could be soub-groups like trainees, junior personnel and senior personnel who all should be able to see and access a different selection of courses.

Yours, Ulrich

Hi, David!

Some ideas:

Maybe there can be three kinds of groups:site-wide, category-wide and course-wide. They can behave similary: site/category group can be enrolled in course, where it acts as a normal group.

On roles and groups: site-wide group can be a kind of context, so the abilities can be defined in it. This will solve all problems with managing groups members (subscriptions and so on).

Site-wide groups in Moodle would rock the LMS universe baby--yeah! Group enrollment should also determine what end user sees on front page upon initial login!

I think this over and find better solution: group should not be a kind of context; group should be in context, similar to a role. If the groups will be created and users assigned to them in particular context, so we can have very flexible system with groups defined on site, category, course and even activity level; also there can be overrides of site group on particular courses (which is needed in large universities). This also will resolve all problems with abilities to manage groups - they also can be given in any particular context.

We are setting up our own eLearning platform and this issue is the one thing stopping me from using Moodle. We have 3 distinct groups of students. Let's call them A, B, & C. We develop courses for each of these unique groups. There are some courses that will be available to all 3 groups. Each group will have approx 500 students in it.
It would be great if when a student registers with the site they are given a key that puts them straight into the relevant group and they then only see the courses specifically for them.This way when a course is developed it has a group assigned to it (the reverse of what it is now) and creates far less administration.

Do you need funding for this feature? We could do with this feature and I may be able to help. Let me know. Al

Hi all, I'm committed to getting this into Moodle 2.0. To help work out funding etc, could everyone here help to flesh out the specification?

http://docs.moodle.org/en/Development:Site-wide_groups

I've made a start with a very simple design - I'd appreciate your feedback on it. Is it enough? What requirements do we need to add?

I've tried to outline a reason for site-wide enrolment on the talk page of the spec. Let me know if things are unclear

As a Moodle implementer within a corporate environment, I can tell you that the ability (however it might be implemented) to hide a course(s) from some users and not others is essential. In my organization's line of work and due to its competitive nature, we are bound contractually by strict non-disclosure agreements. Members of one project team for a client cannot be privy to ANY information from another client project. This includes content AND even the names of courses that may be project-specific. Right now, we are going to have to create our own "points of entry" into courses, bypass the site page, so as to avoid a list of courses being seen. We will probably use the experimental groupings feature to hide content. IMO, this seems like a lot of administration to accomplish this. As an enthusiastic advocate of Moodle myself, I can say that, although my company is implementing Moodle, I suspect other corporate users seeking a VLE, look at the lack of this feature as a major liability. Long story short, please implement this functionality. I am not a software developer, but I do a lot of applications testing and would be willing to offer my assistance in that area as well as documentation.

Bob,

I agree with this. I've made a quick note in the docs wiki regarding the inclusion of Groupings which on the face of it would meet these needs. I'm not a developer either. It would be useful if you could add one or more use cases to help firm up the specification.

Ray, thanks for your post. I actually did add some info to the spec that Martin started. As I gain any more thoughts relevant to that, I will post them there.

Petr's issue "anything that goes across courses brings trouble, this is definitely not easy to solve " can easily be resolved in this case.

We allow groups to be created both at the site level and at course level. In the course setting, a new option needs to be added to select "Site Groups" or "Course Groups" . Thats it !

Have groups selected at site level is a necessity , we need this feature and i've voted for it

This is probably a little late in the game, but we've developed a basic Site Groups plug-in for 1.9x. It was developed to meet the specific needs of our schools but I thought I'd post this message here in case it's of any use.

Screenshots and download are located here: http://moodle.org/mod/data/view.php?d=13&rid=2652&filter=1,

Cheers,
Fernando

The low tech workaround to some of the issues identified here is simply to define each cohort of students or other entity as a hidden course

This can then be used with metacourse to spawn course enrolments fro particular classes. (we also use export grade report to get an Excel list of students from a hidden class then tweak and upload the users into the required course)

The extension of this is that metacourse can also be used to aggregate cohorts into larger entities eg:

Institution wide: year group: class group

or

Institution wide: Campus A, B, C: Yeargroup 1,2,3 class a,b.c

This is definitely going to be in Moodle 2.0.

The final technical spec is taking shape here http://docs.moodle.org/en/Development:Cohorts

Cohorts are basically implemented now in 2.0, with cohort sync enrolment (thanks, Petr, this was a big one!)

Major remaining issues from the requested features are:

MDL-22867 Implement one-time "manual" enrolment of a cohort
MDL-22927 Implement support to specify a course group for cohort users (sync and one-time)