Development:Groups: Difference between revisions
| (29 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
== | {{Moodle 1.9}} | ||
==Improved groups/groupings design in Moodle 1.9== | |||
The groups related database structure in 1.9 was reverted to 1.7, groupings are now implemented in a different way than in 1.8. The current design is compatible with 1.7 style groups. | |||
== | ==Alternative rejected proposals== | ||
* [[Obsolete:Groupings OU]] | |||
* [[Obsolete:Groupings and Groups]] | |||
''Solution:'' Each group | ==Changed groups/groupings relationship== | ||
In 1.8 both groups and groupings are not linked strictly to one course, you could use one group in several courses and groupings at the same time. This loose relationship of groups and groupings adds too much complexity and could be/is a source of bugs in code. | |||
''Solution:'' Each group and grouping links the course id directly. Groupings are only limiting the number of usable groups in activities. This allows free sharing of groups in groupings inside course without potential problems. This idea was proposed by Enrique. See attached db schema. | |||
[[Image:groupsdb.png]] | [[Image:groupsdb.png]] | ||
Benefits | ===course=== | ||
* groupingid - default grouping used in course (new activities, etc.) | |||
===course_modules=== | |||
* groupingid - grouping used in activity | |||
* groupmembersonly - limit access to and visibility of activity based on group membership - if user is not member of at least one group in grouping, the activity is invisible for them; this needs a new shared option in course/moodleform_mod.php | |||
===groupings_groups=== | |||
renamed table | |||
===groups=== | |||
reverted to pre 1.8 state (with the password exception) | |||
===Benefits=== | |||
*fewer tables | *fewer tables | ||
*normalized | *normalized | ||
*simpler SQL | *simpler SQL | ||
* | *easier backup/restore implementation | ||
*fully compatible with old group implementation in 1.7 | |||
==Global groups== | |||
Global groups are not implemented in 1.9. They are not going to be implemented at the database level. Instead some other solution should be present in 2.0. This will require patching of enrolment framework and group/lib.php. | |||
==Groups API== | |||
Main public API is in lib/grouplib.php, modules should use only these functions. | |||
Moodle core may use other functions defined in group/lib.php | |||
== See also == | |||
* [[Development:Groupings and Groups|Enrique Castro group specification]]. | |||
* [[Development:Groupings OU|Open University group specification]]. | |||
==New feature ideas== | |||
===Student self selection of group from grouping=== | |||
To be implemented as normal module. | |||
==Linked groups== | ===Linked groups=== | ||
It would allow synchronizing of group membership from different courses; the idea is to have ''linkid'' in groups table and synchronize the groups membership in group functions for adding/removing of members for groups with the same ''linkid''. | |||
==Group/grouping cloning== | ===Group/grouping cloning=== | ||
Cloning or duplicating is UI feature only, it helps to prefill new groups/groupings with existing data. In theory it could also copy existing grouping setups from other courses too. | |||
== | ===Context-assigned groups instead of just global groups=== | ||
Groups can reuse context subsystem, so that there can be site, category, course and even activity-level groups, when low-level context can override group membership. This allows for more flexible system (there are common cases in universities, when groups are altered in 1-2 courses), and also for reusing of existing code. | |||
Also some modules make use of the teachers, assigned to the groups they taught. There seems to no way that this can be useful with site-wide groups, but context-wide groups can easily retain this functionality. | |||
[[Category:Developer]][[Category:Groups]] | |||
Latest revision as of 09:37, 29 November 2010
Improved groups/groupings design in Moodle 1.9
The groups related database structure in 1.9 was reverted to 1.7, groupings are now implemented in a different way than in 1.8. The current design is compatible with 1.7 style groups.
Alternative rejected proposals
Changed groups/groupings relationship
In 1.8 both groups and groupings are not linked strictly to one course, you could use one group in several courses and groupings at the same time. This loose relationship of groups and groupings adds too much complexity and could be/is a source of bugs in code.
Solution: Each group and grouping links the course id directly. Groupings are only limiting the number of usable groups in activities. This allows free sharing of groups in groupings inside course without potential problems. This idea was proposed by Enrique. See attached db schema.
course
- groupingid - default grouping used in course (new activities, etc.)
course_modules
- groupingid - grouping used in activity
- groupmembersonly - limit access to and visibility of activity based on group membership - if user is not member of at least one group in grouping, the activity is invisible for them; this needs a new shared option in course/moodleform_mod.php
groupings_groups
renamed table
groups
reverted to pre 1.8 state (with the password exception)
Benefits
- fewer tables
- normalized
- simpler SQL
- easier backup/restore implementation
- fully compatible with old group implementation in 1.7
Global groups
Global groups are not implemented in 1.9. They are not going to be implemented at the database level. Instead some other solution should be present in 2.0. This will require patching of enrolment framework and group/lib.php.
Groups API
Main public API is in lib/grouplib.php, modules should use only these functions.
Moodle core may use other functions defined in group/lib.php
See also
New feature ideas
Student self selection of group from grouping
To be implemented as normal module.
Linked groups
It would allow synchronizing of group membership from different courses; the idea is to have linkid in groups table and synchronize the groups membership in group functions for adding/removing of members for groups with the same linkid.
Group/grouping cloning
Cloning or duplicating is UI feature only, it helps to prefill new groups/groupings with existing data. In theory it could also copy existing grouping setups from other courses too.
Context-assigned groups instead of just global groups
Groups can reuse context subsystem, so that there can be site, category, course and even activity-level groups, when low-level context can override group membership. This allows for more flexible system (there are common cases in universities, when groups are altered in 1-2 courses), and also for reusing of existing code.
Also some modules make use of the teachers, assigned to the groups they taught. There seems to no way that this can be useful with site-wide groups, but context-wide groups can easily retain this functionality.
