OK, lets add some use cases. These come from teacher demands I have experienced at ULPG moodle site. Those demands triggered our development of groupings for 1.6.
Grouping Project A: ProjectA01, ProjectA02, ... ProjectA25 (25 groups of 3 people)
Each 3-member team work in a different topic These groups are used in a Wiki and a forum.
Grouping Writing: Writing01, Writing02, Writing03 .. Writing12 (12 groups of 5 people)
Each 5-member team work in a different topic These groups are used in a Wiki and a forum.
The teacher detects that Project03, Project17, Writing9 and Writing12 are working on related topics and have specific needs. He decided to add some resources for them and only them to see.
Set up a Resource page as separate groups using Grouping Special =(Project03, Project17, Writing9, Writing12)
I know, this may be done with other tools:
a) the additional material could be added to the Forum, but that means the teacher needs to replicate 4 times the same message (six, eight times?) Each time he wants to update information, the replication issue arises again
b) Creating a new Special group and putting it into Special Grouping. Ok ¿But what about people changing group? Teacher need to keep track that those on Project03, Project17, Writing9 and Writing12 were added to Special and review Special each time the other groups are changed. A task on teacher shoulders that supposedly CMS tool was making easier, automatic, not more complex.
Several teachers share a course. Each teaches a "Theory" group,
Grouping Sections= Theory01, Theory02, Theory03 each with one teacher in it
Forum News uses grouping Sections as separate groups: allows announcements for all students and for each sections independently.
Grouping Labs= Lab01, Lab02, ... Lab06. Each teacher is responsible for 2 Lab groups.
Wiki Lab results uses grouping Labs for students to write lab reports
Students are distributed at Lab and Theory groups at will: there is no rule like Theory01 students go to Lab01+Lab02 groups.
Each one of three teachers wants a "Doubts" forum accessible only for the students they teach, and
In addition, they want to add content (resources) private for their students
Solution: Each teacher have a Grouping. For instance, TeacherA grouping=(Theory1+Lab01+Lab03). In this way each teacher can add activities or resources that only their set of students can access.
Alternative: creating additional groups and adding users manually, again. I anticipate that if we go this route then in a near future we will discussing ways to "clone" groups and synchronize membership from one to other: Teachers demanding that members of GroupA become members of groupB automagically. Sharing groups makes this unnecessary.
Example D: overcoming a known problem in forum
When you have a forum working in "separate groups" mode the teacher can post a message to "all participants" but those messages are "read-only": students cannot reply to that post due to different groupid.
Course with two sections
Grouping Sections= (English101, English102). Each with a teacher
Grouping Project=(Project01, Project02, Project03 ... Project12, + English101, English102)
Now students are provided with a forum for private discussions about the projects. The teachers can use English101/102 to start a discussion related to these projects that concerns to all their students.
This may be done alternatively with a separate forum for those "project but common" discussions. But most teachers (and students) want to keep topics organized. Not having a "general forum" for any type of discussions. Questions about projects in the projects forum, questions about theory in the class forum.
Example F. Using global groups
Global grouping "Foreign Students"=(Resident, Erasmus, Non-UE)
Global Grouping "Disabilities"=(Disabled) (Disabled people are entitled by law to certain benefits: specially composed texts, exams ... )
Now go to course level. A course with two sections.
Grouping Sections= (Chemistry101, Chemistry102)
The teachers have a News forum in separate groups mode for general announcements, exam warnings etc. Usually Erasmus students are in an "special regime" and are a separate target for many messages and instructions.
If group sharing across groupings were allowed it would be possible to just add global group Erasmus to course grouping Sections and have News forums to manage (Section01, Section02, Erasmus) as separate groups.
If not, teachers have to add a whole new forum "News for foreigners" using "Foreign Students" grouping. And students have to watch for news at two different forums.
You have some resources or activities specially developed for students with disabilities. Let say, special reading texts. They are configure ti use Grouping=Disabilities. You have some immigrant students with a low level of communication language that could also benefit from accessing those resources. You may duplicate those, now using a local Grouping Special. If you could create a local Grouping Special=(global Disabled + local special) they all would access to the same resources or activities.
I think this is a significant limitation, with your scheme global Groupings are shared, rather than individual global Groups. And you cannot create a grouping at course level using course-local groups and global groups together. I do not see many use cases to utilize strictly global groupings at course activities. Such rigid global groupings/groups are useful mainly for enrolement purposes, not actual use in activities.
So, let see the disagreements
>1/ sharing of groups in course groupings
> * minuses: more complex code + needs UI
Needs a different UI, yes, actually a one much more like the classic one, Please see images at http://docs.moodle.org/en/Development:Groupings_and_Groups and working demo at http://moodle.ulpgc.es/moodle19ulpgc/course/view.php?id=3 (login as "prof01" password "moodle" or "estudiante01" password "moodle")
Code complexity? Only that you cannot deduce uniquely the groupingid from groupid. However, that's not usually the task but the other way around. Groupingid must come from $course or $cm objects
> * pluses: please describe, the above use case
I do make a point on group sharing at course and site level. I would see the potential uses of groups severely handicapped if not allowed to share groups.
2/ orphan groups
> * minuses: more complex code
I have perform the hack to get groupings twice at ULPGC site. Fisrt with 1.5 I did use a "default grouping" to hold course groups if no grouping was created explicitly. When we upgraded to 1.6 I refactored the system and I got a "simper" framework without that "default grouping". Of perhaps, is simply that the second time I was more familiar with groups functions.
> * pluses: please describe - me, Martin and OU think there are none
Mainly teacher confort. Groups and groupings are demanded and a required feature, but not all teachers need groupings. If groups are used only for separate course sections then old-style moodle is enough. Presenting a UI where first groupings are to be created and then groups added within is a complication there.
On the other hand, restoring old backup copies from 1.6, 1.5 versions into >1.8 versions would be more natural if "orphan groups" (groups with a courseid but no groupingid associated) are preserved: better backward compatibility. If not , restore functions must ensure that "default grouping" is created and associated with orphan groups coming from the backup.
I do not see this point of orphan groups as crucial. This is a minor implementation detail: choosing if modifying a piece of the code or the other bu the important features for the teacher will work either.
With respect to the other concerns,
I am by no mean a DBA.
I have been inspecting the code for the most used complex functions in groups API, those that allow you to retrieve groups for a user and compare how the task woul be done with your 4-table fixed-grouping scheme or the six-table loose OU scheme. In all cases the complexity of the queries is similar. In OU scheme there are more tables, but not all are used simultaneously.
groups_get_groups($courseid): 2-table join vs 1-table query if only groupids are need, a 2-table
groups_get_groups_in_grouping($groupingid): 1-table query vs 1 if only groupids or a 2-table join for group objects
groups_get_groups_for_user($userid, $courseid): both schemes use a 3-table join
groups_get_groups_for_user_in_grouping($userid, $groupingid): 2-table join vs a 2-table join for groupids or a 3-table join for group objects
groups_is_member_of_some_group_in_grouping($userid, $groupingid): both 2-table joins
groups_get_groups_not_in_grouping($groupingid, $courseid): both 2-table joins
So, it seems that some functions may be slower for the 6-table UO scheme, but other are actually simpler. I do not think that to avoid the extra complexity of groups_get_groups_for_user_in_grouping($userid, $groupingid) using a 3-table join we should refuse to use the extra flexibility of the scheme. How much slower would be this function with one and the other scheme? Is it worth that extra speed the lack of group sharing between groupings.
Restricting access to resources and activities
Yes, the implementation makes the restriction for "separate groups" mode only: if groups are separated and you are not in any group you are off-limits. For instance in a separate groups forum ungrouped students cannot participate in the discussions. I think that adding a new attribute "restricted" distinct from "groupmode" would break that intuitive understanding.
As for Resources, I see it as a natural extension. Think of a "group mode" Resource as a "group wiki": you have in fact several wikis, one for each group. I am not thinking in adding such multipage capability to resources in any time in a near or distant future.
For the moment: you setup the resource as "separate groups" and those "not grouped" cannot access. That's the only "use of groups" of the resource module (Resources are modules, after all). But in future other "uses of groups" may arise.
I agree with the general view, simplification into one library file, with a reduction of overall API functions. Indeed may are not used nor needed for modules to use groups powerfully . I would use, as in other parts of Moodle, default parameters to combine some of them.
Throwing away the legacy functions is drastic but feasible: those functions are not called that much. I can mention that I hacked modules in 1.5 and 1.6 for groupings in less than a week once I had the groups functions clear in library.