Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-28225

Implement Groupings in 2.0.x and 2.1

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Not a bug
    • Affects Version/s: 2.0.3, 2.1
    • Fix Version/s: None
    • Component/s: Course, Groups
    • Labels:
    • Database:
      Any
    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE

      Description

      Despite being a robust feature of the 1.9 branch a key element of this functionality has been deprecated in 2.0.x and 2.1. See MDL-28190

      My understanding that 1.9 Groupings were NOT experimental and only remained in that part of the admin menu as there was no obvious place to re-locate them.

      In 1.9 groupings were available for all activity and resource types. This functionality doesn't make much sense if this is not the case.

      Groupings are used widely across the activity and resource range, demoting a significant part of their scope to "experimental" is retrograde step that
      reduces confidence in Moodle.

      The ability to manage differentiation of all types of course content i.e. resources and activities needs to be fully (re)implemented at the earliest opportunity.

        Gliffy Diagrams

          Issue Links

            Activity

            ray Ray Lawrence created issue -
            Hide
            ray Ray Lawrence added a comment -

            Increasing priority and adding Petr and Martin as watchers.

            Show
            ray Ray Lawrence added a comment - Increasing priority and adding Petr and Martin as watchers.
            ray Ray Lawrence made changes -
            Field Original Value New Value
            Priority Minor [ 4 ] Major [ 3 ]
            Hide
            ray Ray Lawrence added a comment -

            Linked to closed issue that notifies that groupings have always been experimental.

            Show
            ray Ray Lawrence added a comment - Linked to closed issue that notifies that groupings have always been experimental.
            ray Ray Lawrence made changes -
            Link This issue blocks MDL-28190 [ MDL-28190 ]
            Hide
            salvetore Michael de Raadt added a comment -

            Petr, could you comment on this. It would be good to show some reasoning behind this decision and if it is likely to change.

            Show
            salvetore Michael de Raadt added a comment - Petr, could you comment on this. It would be good to show some reasoning behind this decision and if it is likely to change.
            salvetore Michael de Raadt made changes -
            Fix Version/s DEV backlog [ 10464 ]
            Labels triaged
            Affects Version/s 2.0 [ 10122 ]
            Affects Version/s 2.0.1 [ 10420 ]
            Hide
            skodak Petr Skoda added a comment - - edited

            Hello,

            first of all groupings are something completely different from "Available for group members only". Grouping is a set of groups - nothing else, before 1.9 all activities had to use the same set of groups, groupings allow you to use only subset of groups in each activity or course. This was experimental in 1.9 and is fully supported now in 2.x, it can not be disabled now.

            groupmembersonly is a hack that makes one activity available for members of any group that is available in the activity, it might be all groups or one particular grouping. This feature was originally controlled by the same experimental setting as groupings in 1.9, you have to enable it in the experimental section if you really want it in 2.x. It is experimental because it has performance cost and there are several known problems (such as in gradebook and reports) that are probably not going to be fixed. It usually works fine in simple scenarios but you may have to use some workarounds elsewhere.

            This groupmembersonly hack is often used when you have groups of students that take course at different times - the problem is that you need different group deadlines for assignments and quizes, this might get implemented soon. Another use case is special hidden resources for tutors - it might be better to use capabilities instead of groups here - OU probably has something like this already implemented.

            To sum it up:
            1/ groupings were designed for something else than you think
            2/ groupmembersonly was never a robust feature - it is marked as experimental for several reasons, nothing was deprecated
            3/ there might be better ways for some use cases in 2.2 or 2.3 than groupmembersonly
            4/ the group/grouping related docs are already being fixed because many people were confused

            Petr

            Show
            skodak Petr Skoda added a comment - - edited Hello, first of all groupings are something completely different from "Available for group members only". Grouping is a set of groups - nothing else, before 1.9 all activities had to use the same set of groups, groupings allow you to use only subset of groups in each activity or course. This was experimental in 1.9 and is fully supported now in 2.x, it can not be disabled now. groupmembersonly is a hack that makes one activity available for members of any group that is available in the activity, it might be all groups or one particular grouping. This feature was originally controlled by the same experimental setting as groupings in 1.9, you have to enable it in the experimental section if you really want it in 2.x. It is experimental because it has performance cost and there are several known problems (such as in gradebook and reports) that are probably not going to be fixed. It usually works fine in simple scenarios but you may have to use some workarounds elsewhere. This groupmembersonly hack is often used when you have groups of students that take course at different times - the problem is that you need different group deadlines for assignments and quizes, this might get implemented soon. Another use case is special hidden resources for tutors - it might be better to use capabilities instead of groups here - OU probably has something like this already implemented. To sum it up: 1/ groupings were designed for something else than you think 2/ groupmembersonly was never a robust feature - it is marked as experimental for several reasons, nothing was deprecated 3/ there might be better ways for some use cases in 2.2 or 2.3 than groupmembersonly 4/ the group/grouping related docs are already being fixed because many people were confused Petr
            Hide
            ray Ray Lawrence added a comment -

            Thanks.

            The "Available for group members only" setting where retained in 2.x is identical to that in 1.9.x. At this end there seems no logical reason to split off identical functionality for all resources and some activities.

            Also, why is this deemed experimental for some activities and not others?

            This partial implementation in 2.x isn't much use from a practical point of view. Not sure where we go from here.

            Show
            ray Ray Lawrence added a comment - Thanks. The "Available for group members only" setting where retained in 2.x is identical to that in 1.9.x. At this end there seems no logical reason to split off identical functionality for all resources and some activities. Also, why is this deemed experimental for some activities and not others? This partial implementation in 2.x isn't much use from a practical point of view. Not sure where we go from here.
            Hide
            skodak Petr Skoda added a comment -

            It is experimental because there are several problems that we can not fix completely - such as gradebook which expects that all students see the same course structure.

            It is not a partial implementation! The groupings work 100% in 2.0, the experimental "group members only" works the same in 1.9 and 2.0 with all the known problems.

            Show
            skodak Petr Skoda added a comment - It is experimental because there are several problems that we can not fix completely - such as gradebook which expects that all students see the same course structure. It is not a partial implementation! The groupings work 100% in 2.0, the experimental "group members only" works the same in 1.9 and 2.0 with all the known problems.
            skodak Petr Skoda made changes -
            Assignee moodle.com [ moodle.com ] Petr Škoda (skodak) [ skodak ]
            Hide
            skodak Petr Skoda added a comment -

            I am going to update docs this week and close this issue, I hope the concept of groupings was explained here properly. Any more questions?

            Show
            skodak Petr Skoda added a comment - I am going to update docs this week and close this issue, I hope the concept of groupings was explained here properly. Any more questions?
            skodak Petr Skoda made changes -
            Link This issue has been marked as being related by MDL-28411 [ MDL-28411 ]
            Hide
            skodak Petr Skoda added a comment -

            I have just fixed the groupings docs and create a new PULL request for lang string improvements in 1.9, I hope that is enough.

            Petr

            Show
            skodak Petr Skoda added a comment - I have just fixed the groupings docs and create a new PULL request for lang string improvements in 1.9, I hope that is enough. Petr
            skodak Petr Skoda made changes -
            Status Open [ 1 ] Closed [ 6 ]
            Fix Version/s DEV backlog [ 10464 ]
            Resolution Not a bug [ 7 ]
            Hide
            ray Ray Lawrence added a comment -

            Thanks. As you have mentioned earlier, the underlying issues remain. I propose that either those issues are added to this one and this issue becomes a meta issue or a new issue is created for the same purpose. The current situation isn't satisfactory in the long term and if it isn't here as an outstanding issue it won't get fixed.

            Show
            ray Ray Lawrence added a comment - Thanks. As you have mentioned earlier, the underlying issues remain. I propose that either those issues are added to this one and this issue becomes a meta issue or a new issue is created for the same purpose. The current situation isn't satisfactory in the long term and if it isn't here as an outstanding issue it won't get fixed.
            Hide
            sudpet Petr Sudicky added a comment -

            Hi Petr, would it be perhaps possible to change the default language string "Available for group members only" to "Available for grouping members only"? We had to do it locally for our site, as many teachers were quite confused why this setting refers to "group members" since it really concerns groupings. It seems to us much clearer this way with the group and grouping settings beeing kept apart (though I understand that they are very much funcionally interconnected). Thank you for your consideration

            Petr

            Show
            sudpet Petr Sudicky added a comment - Hi Petr, would it be perhaps possible to change the default language string "Available for group members only" to "Available for grouping members only"? We had to do it locally for our site, as many teachers were quite confused why this setting refers to "group members" since it really concerns groupings. It seems to us much clearer this way with the group and grouping settings beeing kept apart (though I understand that they are very much funcionally interconnected). Thank you for your consideration Petr
            Hide
            skodak Petr Skoda added a comment -

            Hi Petr, I strongly disagree, sorry.

            Show
            skodak Petr Skoda added a comment - Hi Petr, I strongly disagree, sorry.
            Hide
            ray Ray Lawrence added a comment -

            Hi Petr (Sudicky),

            I still think this whole area is a problem (and that this modest change wouldn't go far to resolving it).

            The need to manage availability of activities and resources (and probably sections) is a fundamental requirement that's met in part by the experimental feature. The issue is that this is a non-feature as HQ resolutely refuse to remove the experimental status.

            I'm now of the opinion that this should be approached in a different way:

            1. Groupings are used to manage which users (as defined by group membership and those group(s) being allocated to a grouping) may participate in an activity. I believe that this is the intention of groupings from previous engagements with Petr Skodak on this topic.

            2. Availability i.e. whether activities, resources and sections are visible to group members should be managed by the now well established Conditional access functionality in 2.x. We've seen this extended in 2.4 to include profile fields, I can't imagine it's a massive job to extend this to incorporate groups or groupings as criteria to manage availability (I suspect the gradebook visibility issues may require some work though).

            Generally, IMO it's ideal not to have the same thing controlled by completely different mechanisms. Those who want to continue with the experimental groupings option could do so if they wished for a reasonable grace period.

            Show
            ray Ray Lawrence added a comment - Hi Petr (Sudicky), I still think this whole area is a problem (and that this modest change wouldn't go far to resolving it). The need to manage availability of activities and resources (and probably sections) is a fundamental requirement that's met in part by the experimental feature. The issue is that this is a non-feature as HQ resolutely refuse to remove the experimental status. I'm now of the opinion that this should be approached in a different way: 1. Groupings are used to manage which users (as defined by group membership and those group(s) being allocated to a grouping) may participate in an activity. I believe that this is the intention of groupings from previous engagements with Petr Skodak on this topic. 2. Availability i.e. whether activities, resources and sections are visible to group members should be managed by the now well established Conditional access functionality in 2.x. We've seen this extended in 2.4 to include profile fields, I can't imagine it's a massive job to extend this to incorporate groups or groupings as criteria to manage availability (I suspect the gradebook visibility issues may require some work though). Generally, IMO it's ideal not to have the same thing controlled by completely different mechanisms. Those who want to continue with the experimental groupings option could do so if they wished for a reasonable grace period.
            Hide
            skodak Petr Skoda added a comment -

            "Groupings are used to manage which users may participate in an activity." - THAT IS NOT TRUE! Grouping is a set of groups - nothing else.

            Show
            skodak Petr Skoda added a comment - "Groupings are used to manage which users may participate in an activity." - THAT IS NOT TRUE! Grouping is a set of groups - nothing else.
            Hide
            ray Ray Lawrence added a comment -

            OK, but if you are not a member of a group that is in a grouping that is associated with an activity e.g. a forum you can't post to the forum?

            Fred is in Group A. Group A is a group in Grouping X. The grouping for Forum 123 is Grouping X. Fred can post to Forum 123.

            Wilma is in Group B. Group B is not in Grouping X. Wilma can't post to Forum 123.

            Show
            ray Ray Lawrence added a comment - OK, but if you are not a member of a group that is in a grouping that is associated with an activity e.g. a forum you can't post to the forum? Fred is in Group A. Group A is a group in Grouping X. The grouping for Forum 123 is Grouping X. Fred can post to Forum 123. Wilma is in Group B. Group B is not in Grouping X. Wilma can't post to Forum 123.

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: