Moodle
  1. Moodle
  2. MDL-28082

Auto-create a grouping for each group created

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.9.11, 2.0.3, 2.1
    • Fix Version/s: DEV backlog
    • Component/s: Groups
    • Labels:
    • Environment:
      any
    • Database:
      Any
    • Testing Instructions:
      Hide

      Create group, check grouping tab to see that a grouping of the same name has been created with the newly-created group as a member.

      Show
      Create group, check grouping tab to see that a grouping of the same name has been created with the newly-created group as a member.
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE, MOODLE_21_STABLE
    • Rank:
      17707

      Description

      Groupings are incredibly useful for restricting access to resources and activities to particular groups. However, it is confusing for instructors to have to create groups and then create groupings before they can restrict access; they find it redundant.

      The groupings feature is really nice if one actually needs to create groups of groups, but most of the usage of this feature that we CLAMP schools see doesn't fall into that category. It would save our instructors a lot of time and confusion if they could simply create groups and then immediately be able to restrict access to resources/activities.

      To make this workflow easier, we created this patch. When a user creates a group, it automatically creates a grouping with the same name and adds that group to it. This means the user can create groups, then immediately use them to restrict access to resources/activities.

      CHANGES: Small file added to group/ and line included in group/lib.php.

      Internal tracker number: CLAMP-333

      1. autogroupings.patch
        2 kB
        Robert Puffer
      2. autogroupings19.patch
        1 kB
        Robert Puffer
      3. autogroupings19b.patch
        0.5 kB
        Caroline Moore
      4. autogroupings21b.patch
        0.5 kB
        Caroline Moore

        Activity

        Hide
        Filter Manager added a comment -

        Thanks for suggesting this.

        This might be worth raising in a forum for discussion. Perhaps you can encourage people to comment and vote for about this improvement from a forum discussion.

        Show
        Filter Manager added a comment - Thanks for suggesting this. This might be worth raising in a forum for discussion. Perhaps you can encourage people to comment and vote for about this improvement from a forum discussion.
        Hide
        Robert Puffer added a comment -

        1.9 PATCH ATTACHED - have backported this for those not finding 2.x ready for primetime this coming season.

        Show
        Robert Puffer added a comment - 1.9 PATCH ATTACHED - have backported this for those not finding 2.x ready for primetime this coming season.
        Hide
        Petr Škoda added a comment -

        Hello,

        groupings were not intended to be used for access restrictions. The "groupmembersonly" is an experimental feature, it creates problems in gradebook and other areas, it affects performance too. I think this patch fits only one experimental use case and is not suitable for everybody.

        Thanks for the report and patch.

        Petr

        Show
        Petr Škoda added a comment - Hello, groupings were not intended to be used for access restrictions. The "groupmembersonly" is an experimental feature, it creates problems in gradebook and other areas, it affects performance too. I think this patch fits only one experimental use case and is not suitable for everybody. Thanks for the report and patch. Petr
        Hide
        Robert Puffer added a comment -

        Hi Petr,
        From the 2.0 documentation on "Groups vs Groupings" (http://docs.moodle.org/20/en/Groups_versus_groupings):
        "To have students working on different activities, not even seeing activities for other groups (such as group A writing a report, group B using a forum, and group C creating a wiki), you need to put them in groups first, such as group A, B, and C, THEN you must place each group in their own grouping, such as Grouping A containing Group A, Grouping B containing group B, etcetera. The only way you can make an entire activity available for only one set of students is to pass through groups to groupings—just like the only way to be on the US Olympic Team is to first have a sport."
        The preponderance of schools affirming the value of this feature seems contradictory to the limited frame of reference you've evidenced here – they actually state succinctly that their MAIN use-case for groupings is precisely to limit activities (and access to confidential data) to a particular subset of the course (students or instructors). In point of fact, I don't find any other user-case for grouping in the documentation mentioned above or in any of the schools with which we're in contact. Perhaps you can suggest another use-case for groupings that would not involve "limit to group members only"? Either way, thanks for commenting.
        – one other note, we're changing the code to check for site-wide "limit to group members only" setting and, if turned off, the code will do nothing (but of course, it would basically be doing nothing anyway, if that setting were turned off)

        Show
        Robert Puffer added a comment - Hi Petr, From the 2.0 documentation on "Groups vs Groupings" ( http://docs.moodle.org/20/en/Groups_versus_groupings): "To have students working on different activities, not even seeing activities for other groups (such as group A writing a report, group B using a forum, and group C creating a wiki), you need to put them in groups first, such as group A, B, and C, THEN you must place each group in their own grouping, such as Grouping A containing Group A, Grouping B containing group B, etcetera. The only way you can make an entire activity available for only one set of students is to pass through groups to groupings—just like the only way to be on the US Olympic Team is to first have a sport." The preponderance of schools affirming the value of this feature seems contradictory to the limited frame of reference you've evidenced here – they actually state succinctly that their MAIN use-case for groupings is precisely to limit activities (and access to confidential data) to a particular subset of the course (students or instructors). In point of fact, I don't find any other user-case for grouping in the documentation mentioned above or in any of the schools with which we're in contact. Perhaps you can suggest another use-case for groupings that would not involve "limit to group members only"? Either way, thanks for commenting. – one other note, we're changing the code to check for site-wide "limit to group members only" setting and, if turned off, the code will do nothing (but of course, it would basically be doing nothing anyway, if that setting were turned off)
        Hide
        Caroline Moore added a comment -

        With check for site-level enablegroupmembersonly setting

        Show
        Caroline Moore added a comment - With check for site-level enablegroupmembersonly setting
        Hide
        Petr Škoda added a comment -

        The docs is wrong here I am afraid, I know it because I reimplemented all the groups/groupings functionality based on previous work/patches of other people, I would not include this feature again if I was doing the integration now. Please note it was always an experimental feature that could be removed at any time.

        Moodle is using role-based access, the "groupmembersonly" experimental feature is just a hack that is abusing group membership. I think Open University already implemented a bit different approach that uses capabilities to restrict activity access - Sam Marshall should know a lot more about that.

        The groups internal implementation needs at least partial rewrite, the code was not updated after the migration to new renderers and new PAGE framework. I am not maintaining this subsystem any more, my personal opinion does not matter much here, all I wanted to do is to explain the original ideas behind the *groupings*.

        Petr

        Show
        Petr Škoda added a comment - The docs is wrong here I am afraid, I know it because I reimplemented all the groups/groupings functionality based on previous work/patches of other people, I would not include this feature again if I was doing the integration now. Please note it was always an experimental feature that could be removed at any time. Moodle is using role-based access, the "groupmembersonly" experimental feature is just a hack that is abusing group membership. I think Open University already implemented a bit different approach that uses capabilities to restrict activity access - Sam Marshall should know a lot more about that. The groups internal implementation needs at least partial rewrite, the code was not updated after the migration to new renderers and new PAGE framework. I am not maintaining this subsystem any more, my personal opinion does not matter much here, all I wanted to do is to explain the original ideas behind the * groupings *. Petr
        Hide
        Robert Puffer added a comment -

        So... if I understand you correctly, there isn't another use-case for groupings other than to limit access to activities and/or privileged information/resources?
        Could the maintainer of groupings weigh in on the future of groupings functionality so the user community can be apprised of what to expect? I'm sorry if this sounds critical but I'm habituated toward having more respect for Moodle's overall planning process and this sounds more like, "hack it and then whack it".

        Show
        Robert Puffer added a comment - So... if I understand you correctly, there isn't another use-case for groupings other than to limit access to activities and/or privileged information/resources? Could the maintainer of groupings weigh in on the future of groupings functionality so the user community can be apprised of what to expect? I'm sorry if this sounds critical but I'm habituated toward having more respect for Moodle's overall planning process and this sounds more like, "hack it and then whack it".
        Hide
        Caroline Moore added a comment -

        Autogroupings with check for 'enablegroupings' setting (1.9)

        Show
        Caroline Moore added a comment - Autogroupings with check for 'enablegroupings' setting (1.9)
        Hide
        Petr Škoda added a comment - - edited

        Groupings define subsets of groups that are available in activity/course - nothing else. That means students may be grouped differently in each activity. The only problem is that some activities do not implement groups at all (glossary) or do not implement it correctly (wiki), gradebook does not support group grading, etc.

        "Group members only" is an experimental feature that limits access to members of currently available groups (all groups if no grouping specified or groups from one specific grouping). Originally the groupings and groupmembersonly were controlled by the same experimental setting, in 2.x the groupings are fully supported and always enabled, groupmembersonly is an experimental feature that is not supported == bugs are not always fixed and it may be removed later (that is why it is marked as experimental).

        I keep explaining this difference since 1.9, please help me to fix all the docs written by people that did not understand this.

        Show
        Petr Škoda added a comment - - edited Groupings define subsets of groups that are available in activity/course - nothing else. That means students may be grouped differently in each activity. The only problem is that some activities do not implement groups at all (glossary) or do not implement it correctly (wiki), gradebook does not support group grading, etc. "Group members only" is an experimental feature that limits access to members of currently available groups (all groups if no grouping specified or groups from one specific grouping). Originally the groupings and groupmembersonly were controlled by the same experimental setting, in 2.x the groupings are fully supported and always enabled, groupmembersonly is an experimental feature that is not supported == bugs are not always fixed and it may be removed later (that is why it is marked as experimental ). I keep explaining this difference since 1.9, please help me to fix all the docs written by people that did not understand this.
        Hide
        Caroline Moore added a comment -

        Hi Petr,

        I apologize, but I still don't fully understand what groupings are intended to do. Other than the experimental "group members only" feature, what can one do with groupings in Moodle? I haven't found any other place in a course where groupings come into play.

        I agree that a lot of work needs to be done on groups; as you mentioned, they are implemented inconsistently across different activities (or not at all in certain places in Moodle). I also agree that Groupings were implemented in a clunky way. If that functionality is being completely rethought/rewritten for a future version of Moodle, I'm all for it!

        However, as things stand right now, the "group members only" feature does what I and all of my faculty expect groups to be able to do. The actual groups functionality is confusing and, as mentioned above, inconsistent. I am hesitant to recommend it to my faculty because of this. Groupings, on the other hand, are complex to set up, but the "group members only" functionality is clear and easy to understand. When used, it also puts a clear label next to each resource/activity link on the course page telling the Teacher which group(ing) can see that resource/activity. This is the functionality my faculty want.

        Since groupings + "group members only" is currently the only way to achieve this, it would be lovely to save everyone a lot of time and confusion and set up the groupings automatically. I've edited my patches so that they check to see if the "group members only" functionality is enabled site-wide before creating a grouping for each group.

        In short, I agree that groups/groupings need to be carefully looked at and probably rewritten in large part. In the meantime, though, this is the way Moodle handles this functionality, and adopting this patch would really improve the usability of the groups/groupings functionality of Moodle for the CLAMP schools' users.

        Show
        Caroline Moore added a comment - Hi Petr, I apologize, but I still don't fully understand what groupings are intended to do. Other than the experimental "group members only" feature, what can one do with groupings in Moodle? I haven't found any other place in a course where groupings come into play. I agree that a lot of work needs to be done on groups; as you mentioned, they are implemented inconsistently across different activities (or not at all in certain places in Moodle). I also agree that Groupings were implemented in a clunky way. If that functionality is being completely rethought/rewritten for a future version of Moodle, I'm all for it! However, as things stand right now, the "group members only" feature does what I and all of my faculty expect groups to be able to do. The actual groups functionality is confusing and, as mentioned above, inconsistent. I am hesitant to recommend it to my faculty because of this. Groupings, on the other hand, are complex to set up, but the "group members only" functionality is clear and easy to understand. When used, it also puts a clear label next to each resource/activity link on the course page telling the Teacher which group(ing) can see that resource/activity. This is the functionality my faculty want. Since groupings + "group members only" is currently the only way to achieve this, it would be lovely to save everyone a lot of time and confusion and set up the groupings automatically. I've edited my patches so that they check to see if the "group members only" functionality is enabled site-wide before creating a grouping for each group. In short, I agree that groups/groupings need to be carefully looked at and probably rewritten in large part. In the meantime, though, this is the way Moodle handles this functionality, and adopting this patch would really improve the usability of the groups/groupings functionality of Moodle for the CLAMP schools' users.
        Hide
        Caroline Moore added a comment -

        Forum discussion on this has been started here: http://moodle.org/mod/forum/discuss.php?d=178708

        Show
        Caroline Moore added a comment - Forum discussion on this has been started here: http://moodle.org/mod/forum/discuss.php?d=178708
        Hide
        Petr Škoda added a comment -

        "group members only" is a nasty hack that may create problems for you (such as in gradebook), that is the reason why it is marked as experimental and unsupported feature. The structure of the course is supposed to be the same for all students. Groupmode is not designed to restrict who can access which activity, it is meant to allow group work inside of activities - students are divided into groups where they cooperate, each group may have a different tutor.

        In my opinion your patch does not make sense if you use the groupings in the intended way. My -1 for inclusion in official distribution.

        Show
        Petr Škoda added a comment - "group members only" is a nasty hack that may create problems for you (such as in gradebook), that is the reason why it is marked as experimental and unsupported feature. The structure of the course is supposed to be the same for all students. Groupmode is not designed to restrict who can access which activity, it is meant to allow group work inside of activities - students are divided into groups where they cooperate, each group may have a different tutor. In my opinion your patch does not make sense if you use the groupings in the intended way. My -1 for inclusion in official distribution.
        Hide
        Robert Puffer added a comment -

        From the "Moodle 2.0 Groupings FAQ":
        "Why is the groupings feature experimental?

        When groupings were added to Moodle, in 1.9.0, it was an experimental feature, in other words it required additional testing and bug-fixing. This has since been done and groupings have proved to be a reliable feature.

        In Moodle 2.0, groupings will be listed as an advanced feature, however to avoid confusion the enablegroupings checkbox in 1.9 will remain in the experimental section of the site administration menu."

        Essentially what this says is that we're going to enable groupings as a full feature (advanced) but will disallow its use for anything meaningful. IMO, if Moodle core development desires to avoid looking totally absurd, either you should back down from your position or another core developer should join the conversation to provide some well-formed judgement.

        Show
        Robert Puffer added a comment - From the "Moodle 2.0 Groupings FAQ": "Why is the groupings feature experimental? When groupings were added to Moodle, in 1.9.0, it was an experimental feature, in other words it required additional testing and bug-fixing. This has since been done and groupings have proved to be a reliable feature. In Moodle 2.0, groupings will be listed as an advanced feature, however to avoid confusion the enablegroupings checkbox in 1.9 will remain in the experimental section of the site administration menu." Essentially what this says is that we're going to enable groupings as a full feature (advanced) but will disallow its use for anything meaningful. IMO, if Moodle core development desires to avoid looking totally absurd, either you should back down from your position or another core developer should join the conversation to provide some well-formed judgement.
        Hide
        Petr Škoda added a comment -

        Hmmm, do you really think you can persuade the person who wrote the code with some docs or faqs that contain misleading/incorrect information? I am going to update all docs and faqs next week.

        Show
        Petr Škoda added a comment - Hmmm, do you really think you can persuade the person who wrote the code with some docs or faqs that contain misleading/incorrect information? I am going to update all docs and faqs next week.
        Hide
        Petr Škoda added a comment -

        And by the way I already stepped down from several areas because of people like you. I am only trying to explain the background of groupings, I am not saying anything about future of groups/groupings because I do not want to be part of it. This is open source, you can change whatever you want, but you can not force others to think the say way you do, you can not demand inclusion of anything into the official distribution. If you do not like it then simply fork moodle repo on github and implement any improvements you like there.

        Ciao

        Show
        Petr Škoda added a comment - And by the way I already stepped down from several areas because of people like you. I am only trying to explain the background of groupings, I am not saying anything about future of groups/groupings because I do not want to be part of it. This is open source, you can change whatever you want, but you can not force others to think the say way you do, you can not demand inclusion of anything into the official distribution. If you do not like it then simply fork moodle repo on github and implement any improvements you like there. Ciao
        Hide
        Robert Puffer added a comment -

        I believe we've supplied ample evidence of our case – why limiting of access is necessary inside the course (which will rarely correspond to roles) and you've failed to supply one use case for groupings but insist on talking around the actual points being made and avoiding direct questions. I feel confident in correcting your interpretation of "open source" (and this is likely the root of our problem) in that open source software shouldn't force users to fork where a consensus of usefulness exists. I don't know you personally and apologize if I've offended you with my remarks (i.e., "people like you") but it would appear that you have limited experience in a real-world setting that would benefit from the type of functionality this quite easy fix provides. Again, I hope we can engage additional core developers who can offer additional perspective.
        Best regards

        Show
        Robert Puffer added a comment - I believe we've supplied ample evidence of our case – why limiting of access is necessary inside the course (which will rarely correspond to roles) and you've failed to supply one use case for groupings but insist on talking around the actual points being made and avoiding direct questions. I feel confident in correcting your interpretation of "open source" (and this is likely the root of our problem) in that open source software shouldn't force users to fork where a consensus of usefulness exists. I don't know you personally and apologize if I've offended you with my remarks (i.e., "people like you") but it would appear that you have limited experience in a real-world setting that would benefit from the type of functionality this quite easy fix provides. Again, I hope we can engage additional core developers who can offer additional perspective. Best regards
        Hide
        Caroline Moore added a comment -

        Petr, Bob and I are not trying to force you to include anything. I'm sorry if it came across that way. We are trying to understand how groupings are intended to be used so we can understand your objections to including our patch.

        I think all three of us are getting confused due to terminology. I'm not sure we're all talking about the same thing when we say "groups" vs. "groupings." When Bob and I say "groups," we mean the "group mode" functionality: no groups, visible groups, or separate groups. When we say "groupings," we mean groups of groups and the ability to restrict access to a particular grouping. Is this what you mean by those two terms as well?

        When you say "In my opinion your patch does not make sense if you use the groupings in the intended way," what do you consider the intended way to use groupings? (Not groups, but groupings.) As far as I can tell, the only available use of groupings in Moodle is to limit access to a particular grouping, aka "group members only" (even though it's restricting by groupings, not groups - I think this is the root of some of the terminology confusion).

        The fact is that groupings is a feature of Moodle (albeit an experimental feature). All we're trying to do with this patch is extend that experimental feature to make it a bit more useful. Our patch only creates groupings from groups if the groupings functionality is enabled at the site level. If people choose not to use groupings, this patch will not affect them in any way. Since, as far as we can tell, restricting access to resources/activities is the only use for groupings (not groups!), we believe this is a feature enhancement that will save users who use groupings a significant amount of time.

        Show
        Caroline Moore added a comment - Petr, Bob and I are not trying to force you to include anything. I'm sorry if it came across that way. We are trying to understand how groupings are intended to be used so we can understand your objections to including our patch. I think all three of us are getting confused due to terminology. I'm not sure we're all talking about the same thing when we say "groups" vs. "groupings." When Bob and I say "groups," we mean the "group mode" functionality: no groups, visible groups, or separate groups. When we say "groupings," we mean groups of groups and the ability to restrict access to a particular grouping. Is this what you mean by those two terms as well? When you say "In my opinion your patch does not make sense if you use the groupings in the intended way," what do you consider the intended way to use groupings? (Not groups, but groupings.) As far as I can tell, the only available use of groupings in Moodle is to limit access to a particular grouping, aka "group members only" (even though it's restricting by groupings, not groups - I think this is the root of some of the terminology confusion). The fact is that groupings is a feature of Moodle (albeit an experimental feature). All we're trying to do with this patch is extend that experimental feature to make it a bit more useful. Our patch only creates groupings from groups if the groupings functionality is enabled at the site level. If people choose not to use groupings, this patch will not affect them in any way. Since, as far as we can tell, restricting access to resources/activities is the only use for groupings (not groups!), we believe this is a feature enhancement that will save users who use groupings a significant amount of time.
        Hide
        Deb Sarlin added a comment -

        This frames how groupings and groups are used by many of us in Higher Education (US) who are long-time Moodle users. Thanks.

        Show
        Deb Sarlin added a comment - This frames how groupings and groups are used by many of us in Higher Education (US) who are long-time Moodle users. Thanks.
        Hide
        Petr Škoda added a comment -

        Caroline and Deb, the facts are:

        1/ grouping is a subset of course groups - nothing else
        2/ groupings are standard feature in 2.x
        3/ if you select grouping in activity only groups from that grouping are "visible" in that activity, if you do not select grouping for activity all groups are visible/available
        4/ groupings were created because people wanted to use different set of groups in each activity - for example you want students to discuss things in forum using separate groups A, B and C, then in assignments you have two tutors one grading group XX the other YY group, then you have wiki where groups Alpha, Beta and Gamma each create one group wiki, then in the participants report you want to see only group1, group2 and group3. Before 1.9.x you could not do this because each activity had to use all course groups.
        5/ group members only is an experimental feature that tries to prevent access to activities based on group membership (many people confuse this with "groupings" which is absolutely wrong)
        6/ group members only has some performance cost
        7/ group members only causes problems in gradebook and other areas because the structure of each course may look different for each student, there are no problems in the teacher view usually - these bugs can not be usually fixed in code and you have to use some clever workaround
        8/ since Moodle 2.0.2 it is internally possible to create access restrictions similar to "group members only" - Sam was working on some special feature for OU which is capability based
        9/ I am not proposing to remove "group members only" because it is too late, but I still wish I've never introduced it into Moodle codebase.

        This is all partially my fault because I did not find enough time to design the groups subsystem, write the implementation, fix bugs and write user docs at the same time. I want to fix it now, that is why I am trying to explain the group/groupings internals here. English is not my native language, sorry for any misunderstandings. I am going to fix all incorrect group/grouping related info in the docs tomorrow and explain everything to Helen so that it is not reverted in the future. Later you can use the talk page in wiki docs to discuss any improvements. I am going to improve the grouping setting name and description in 1.9x soon.

        Show
        Petr Škoda added a comment - Caroline and Deb, the facts are: 1/ grouping is a subset of course groups - nothing else 2/ groupings are standard feature in 2.x 3/ if you select grouping in activity only groups from that grouping are "visible" in that activity, if you do not select grouping for activity all groups are visible/available 4/ groupings were created because people wanted to use different set of groups in each activity - for example you want students to discuss things in forum using separate groups A, B and C, then in assignments you have two tutors one grading group XX the other YY group, then you have wiki where groups Alpha, Beta and Gamma each create one group wiki, then in the participants report you want to see only group1, group2 and group3. Before 1.9.x you could not do this because each activity had to use all course groups. 5/ group members only is an experimental feature that tries to prevent access to activities based on group membership (many people confuse this with "groupings" which is absolutely wrong) 6/ group members only has some performance cost 7/ group members only causes problems in gradebook and other areas because the structure of each course may look different for each student, there are no problems in the teacher view usually - these bugs can not be usually fixed in code and you have to use some clever workaround 8/ since Moodle 2.0.2 it is internally possible to create access restrictions similar to "group members only" - Sam was working on some special feature for OU which is capability based 9/ I am not proposing to remove "group members only" because it is too late, but I still wish I've never introduced it into Moodle codebase. This is all partially my fault because I did not find enough time to design the groups subsystem, write the implementation, fix bugs and write user docs at the same time. I want to fix it now, that is why I am trying to explain the group/groupings internals here. English is not my native language, sorry for any misunderstandings. I am going to fix all incorrect group/grouping related info in the docs tomorrow and explain everything to Helen so that it is not reverted in the future. Later you can use the talk page in wiki docs to discuss any improvements. I am going to improve the grouping setting name and description in 1.9x soon.
        Hide
        Paul Fynn added a comment -

        Petr,

        many thanks for all your work on groupings, which has become an essential feature for our institution where we can have all students in a semester taking a set of courses, but starting at different times.

        The way that we use this is to have a core page common to all students, who are then subdivided into groups (classes), with assignment and coursework submissions set for each group. Each group sees core course info, then their own specific content and dates.

        On our 1.9 version the only change that I would prefer to see would be to put the check box 'group members only' before the groupings box.

        In terms of 2.0, I'd like to be able to pick up the groups (possibly also groupings) automatically from the title of the linked metacourses. I'm not clear whether cohorts will link with groups and groupings, but it seems intuitive that it should.

        I would like to see 'group only' retained in 2.0, unless there is a suitable replacement, as it certainly pays its way..

        best wishes
        Paul

        Show
        Paul Fynn added a comment - Petr, many thanks for all your work on groupings, which has become an essential feature for our institution where we can have all students in a semester taking a set of courses, but starting at different times. The way that we use this is to have a core page common to all students, who are then subdivided into groups (classes), with assignment and coursework submissions set for each group. Each group sees core course info, then their own specific content and dates. On our 1.9 version the only change that I would prefer to see would be to put the check box 'group members only' before the groupings box. In terms of 2.0, I'd like to be able to pick up the groups (possibly also groupings) automatically from the title of the linked metacourses. I'm not clear whether cohorts will link with groups and groupings, but it seems intuitive that it should. I would like to see 'group only' retained in 2.0, unless there is a suitable replacement, as it certainly pays its way.. best wishes Paul
        Hide
        Petr Škoda added a comment -

        Paul,

        your use case is valid, groupmembersonly is not going to be removed. There might be some similar new features in the future - I will not be probably inolved much in that though.

        I would like to work more on cohorts for Moodle 2.2 soon, I am not sure yet what and how will be implemented. I will be looking for feedback throught moodle.org forums.

        Petr

        Show
        Petr Škoda added a comment - Paul, your use case is valid, groupmembersonly is not going to be removed. There might be some similar new features in the future - I will not be probably inolved much in that though. I would like to work more on cohorts for Moodle 2.2 soon, I am not sure yet what and how will be implemented. I will be looking for feedback throught moodle.org forums. Petr
        Hide
        Caroline Moore added a comment -

        Hi Petr,

        Thank you! This - "groupings were created because people wanted to use different set of groups in each activity" - makes everything clear. As far as I know, this use of groupings was not implemented in 1.9, which is what I currently run. I wasn't aware that this was the real purpose of creating groupings, but it does make a lot of sense.

        I understand your hesitation to encourage people to use a feature that's not fully functional. If you don't want to roll this into core for that reason, that's understandable. However, I consider the "groupmembersonly" functionality to be extremely important. Is there a plan to implement a different, better-formed way of achieving this functionality in a future version of Moodle?

        ~Caroline

        Show
        Caroline Moore added a comment - Hi Petr, Thank you! This - "groupings were created because people wanted to use different set of groups in each activity" - makes everything clear. As far as I know, this use of groupings was not implemented in 1.9, which is what I currently run. I wasn't aware that this was the real purpose of creating groupings, but it does make a lot of sense. I understand your hesitation to encourage people to use a feature that's not fully functional. If you don't want to roll this into core for that reason, that's understandable. However, I consider the "groupmembersonly" functionality to be extremely important. Is there a plan to implement a different, better-formed way of achieving this functionality in a future version of Moodle? ~Caroline
        Hide
        Petr Škoda added a comment - - edited

        Caroline,
        it would be great if there was a plan. It would have to probably address multiple uses of groupmembersonly:
        1/ group deadlines for quiz/assignments - groups of students taking course at different times (Tim Hunt likes this idea)
        2/ activity "removing" based on capabilities - used for tutor forums or resources (OU was interested in this I think) - something ordinary users are not supposed to see (at present you can limit access, but you can not remove it completely, you can only hide it)

        Anything else major is missing in the list?

        Show
        Petr Škoda added a comment - - edited Caroline, it would be great if there was a plan. It would have to probably address multiple uses of groupmembersonly: 1/ group deadlines for quiz/assignments - groups of students taking course at different times (Tim Hunt likes this idea) 2/ activity "removing" based on capabilities - used for tutor forums or resources (OU was interested in this I think) - something ordinary users are not supposed to see (at present you can limit access, but you can not remove it completely, you can only hide it) Anything else major is missing in the list?
        Hide
        Robert Russo added a comment -

        We've been debating making the gradebook totally group / grouping aware, meaning being able to assign items to groups / groupings individually.

        This would allow for significantly more complex course designs as well as allow for much greater use of selective release.

        One use case is to automatically create / assign groups to users who fail to meet certain benchmarks and assign them remedial material which is only counted for users in their group.

        Another use case is for cross discipline courses. Allow multiple courses within the same shell taught and graded differently.

        Another use case is to have students taking courses for different credit hours to be graded differently with additional grade items.

        If we get to it at all depending on community / LSU support, we won't be able to get to it until the rest of our gradebook is ported to 2.3dev in late May.

        We've had many of our instructors ask for this, but we've insisted they split their groups (we call them sections) into separate courses.

        Show
        Robert Russo added a comment - We've been debating making the gradebook totally group / grouping aware, meaning being able to assign items to groups / groupings individually. This would allow for significantly more complex course designs as well as allow for much greater use of selective release. One use case is to automatically create / assign groups to users who fail to meet certain benchmarks and assign them remedial material which is only counted for users in their group. Another use case is for cross discipline courses. Allow multiple courses within the same shell taught and graded differently. Another use case is to have students taking courses for different credit hours to be graded differently with additional grade items. If we get to it at all depending on community / LSU support, we won't be able to get to it until the rest of our gradebook is ported to 2.3dev in late May. We've had many of our instructors ask for this, but we've insisted they split their groups (we call them sections) into separate courses.
        Hide
        Robert Puffer added a comment -

        We've taken the groupings auto-creation to the next (logical?) step by managing cross-listed courses, i.e., creating one moodle course combining all the cross-listed sections and a group/ grouping for each cross-listed section. Moving the gradebook to that next level of being grouping-aware would be excellent and the necessary next step.

        Show
        Robert Puffer added a comment - We've taken the groupings auto-creation to the next (logical?) step by managing cross-listed courses, i.e., creating one moodle course combining all the cross-listed sections and a group/ grouping for each cross-listed section. Moving the gradebook to that next level of being grouping-aware would be excellent and the necessary next step.
        Hide
        Robert Russo added a comment -

        Agreed.

        The problem is that the group members only thing is a nasty hack in its current state.

        I would like for the feature to be re-implemented in a sane manner. The gradebook is a big part of that. We're always willing to work with others to get this done, just not until late May. I know what Petr is going through and I appreciate his honesty.

        Besides the performance issues, the biggest problem is assigning a graded item to one group leaves the other group with empty grades, which may be acceptable in SWM or Weighted Mean when not counting empty items, but instructors have to be diligent to enter zero for students who have not taken graded assignments of any kind. If the instructor is using SUM, they are screwed and cannot use the group members only feature with graded items in their course.

        Hopefully we can all get together and plan a complete solution for these use cases sometime in the future. For now, we can limp along.

        Show
        Robert Russo added a comment - Agreed. The problem is that the group members only thing is a nasty hack in its current state. I would like for the feature to be re-implemented in a sane manner. The gradebook is a big part of that. We're always willing to work with others to get this done, just not until late May. I know what Petr is going through and I appreciate his honesty. Besides the performance issues, the biggest problem is assigning a graded item to one group leaves the other group with empty grades, which may be acceptable in SWM or Weighted Mean when not counting empty items, but instructors have to be diligent to enter zero for students who have not taken graded assignments of any kind. If the instructor is using SUM, they are screwed and cannot use the group members only feature with graded items in their course. Hopefully we can all get together and plan a complete solution for these use cases sometime in the future. For now, we can limp along.
        Hide
        Nadav Kavalerchik added a comment -

        We also hacked the same feature on Moodle 19. And was about to hack the same feature in Moodle 2.4/5
        And was very happy to see a tracker about it. So... 1 or from me (Us) too

        Show
        Nadav Kavalerchik added a comment - We also hacked the same feature on Moodle 19. And was about to hack the same feature in Moodle 2.4/5 And was very happy to see a tracker about it. So... 1 or from me (Us) too

          People

          • Votes:
            35 Vote for this issue
            Watchers:
            15 Start watching this issue

            Dates

            • Created:
              Updated: