The code looks pretty good but I think I'm against adding this feature because this is exactly what groupings already does, and groupings have other benefits.

If you are splitting activities so that only certain groups can access them then there is probably a 'meaning' between those groups (e.g. you put half the groups into the red team and half into the blue team) in which case you might want to reuse this on multiple activities and therefore a grouping is more appropriate.

Could we achieve this instead by making it easier to create groupings? For example... I'll try to add a picture, hang on.

Added UI Mockup: <Quick grouping creation>

Hi Sam, I wrote this code as there seemed to be interest from the community (http://tracker.moodle.org/browse/MDL-29538) for something simple like this to be implemented. A lot of users complained about groupings being too complicated.

Sure, I understand why you've done it and it may be useful to people as a patch. I'm just saying I recommend against including it in core code because at least currently, I don't think this is a good solution to the problem (that groupings are a bit complicated/fiddly, especially if you really want single-group groupings).

Hi Mark,
Thank you for developing this it is certainly something that I would use.

Hi Sam,
I have always had a problem with groupings as they always seemed like they did not fit too well with the flow of setting up a course.

To me if I have got all my students into groups I should then be able to use them. I can for forums or in assignments to have one activity but split. If I wanted to create an activity for just one group then I had to go all the way back in and create a grouping where in most circumstances my group==grouping. Also for me the splitting only really worked for forums, the assignments I would usually want two as I would most likely have separate deadlines for each group.

All this was before the conditional code was added. Now to me it seems logical that a grouping is really a group condition. If I have a group set up already and I am setting up the conditions for an activity then making it an option there just seems right.

I understand what you are saying regarding forums and activities that already have a group mode but maybe a note/warning could appear in the conditional area for these courses stating that?

I do think an average member of staff would add a forum and assume it was for all students. Then if they wanted two groups to have distinct forums they would just create two and have conditions set. Yes they would have two forums where one would suffice but they would accept it as it would just make sense.

I don't know if the code is in place for conditions to be plugins but if they were then I would use the date/time plugin, the grade plugin and the groups plugin, I would probably not use the cohort plugin.

Matthew: My point is about code bloat - it's nothing to do with the user interface. I'm not certain I'm right here, but just from initial consideration, I don't think we should have two back-end systems that do the same thing (enforce a restriction so that an activity is available only to one or more groups).

In other words the decision should be:

1) What is our back end going to be - are we going to use groupings backend (which already exists and works) or are we going to add new backend code to consider groups as part of the conditional availability code (as included in this patch)? This is the part where I don't think the answer should be 'both'.

In addition grouping provides a significant extra functionality - you can divide students into different groups (larger or smaller) for different activities. In your situation this may be less commonly used so perhaps you don't see it as important, but in our situation it's relatively frequent (whereas we literally never need to restrict activities to single groups). So at least from my point of view it seems that getting rid of groupings and replacing it with this is not an acceptable solution. Therefore we should keep the groupings back end...

and only then

2) What is our user interface going to be?

For example, one option for user interface would be to have a radio button that says 'Restrict to selected groups' and lets you choose a group (or multiple groups) from a list. This user interface would achieve what you want, would it not? But it could be implemented by automatically turning on 'groupmembersonly' option and creating or modifying a grouping [maybe with slight extension to groupings table to record that it was automatically created and 'belongs' to that activity]. Then there would be no changes to any other area of code, only to the code for handling that form.

So let me emphasise, I'm not trying to defend the groupings interface - it's good for arranging sets of groups, but very poor when you want to restrict a single activity to a single group. I think it should be improved (e.g. my suggestion in point 2 just above, or the interface I mocked up in the 'Quick grouping creation' image attached to bug), but I don't see the argument for duplicating the back-end code.

Hi Sam,
I understand where you are coming from about the backend duplication but I do believe that the introduction of Conditional Activities into core has opened up the floodgates for possibilities that this falls into.

The Conditional Activities were added in 2.0 and provided Grade and Date conditions that I do not believe currently are plugins. Already Date has become Date+Time as of 2.2 and in the tracker we now have patches for Cohort and Group conditions. I think I also saw conditions for User Fields such as dept, country etc.

To me this would suggest that if it has not been considered by HQ already then the Conditions should use plugins where the admin could add the ones available at a site level like the enrolment plugins.

From this thread it would seem that a Groupings plugin would work for the OU. The groupings could be created exactly as they currently are but they would be allocated to the course within the Restrict Access section of the Settings rather than the Common Module section.

This would require a reworking of the Restrict Access section of the Course Settings page. It would seem to make sense for an Add Condition button that launched a modal dialog that contained buttons for each of the available plugins.

I appreciate this is not a small or simple thing but I do think it should be considered as the number of patches would suggest that Conditions are a very popular new feature.

Yes there are lots of possibilities and lots of them are great! But, if we rewrite the whole controls around access to activities to use a plugin system we might still prefer to have a single plugin for groupings and make its interface not suck, rather than creating two plugins one for groupings and one for groups that do basically the same thing.

I agree rewriting it to use a plugin system would be a great idea and it's a shame I didn't write it that way to begin with. Is there a tracker issue for that?

Unfortunately, my employer doesn't currently have any requirements in that area which means I probably can't work on it, although I'll keep an eye out for any requirements that would lead to such a system because it would be great to have an excuse. (I'm currently rewriting the media embedding into a [kind of] plugin system because they do have requirements for that!)

Conditional plugins is a great idea, however sounds like it would be a bit of a headache to convert the existing data for this. I agree that having two ways of achieving the same functionality is confusing and not needed I am not fussed about either way, just thought I would write the code as it was requested in http://tracker.moodle.org/browse/MDL-29538

Also, regarding that tracker issue, did you have time to check the code to see if you could put it in core? I wrote this code for an existing client who has been using it for sometime without any issues afaik.

Mark - I haven't had time to review the code in MDL-29538 yet - basically I appear to have no time to do anything at the moment. Most of our Moodle 2 courses start in February (there are only a few already running) which means there is major panic about whatever minor glitches there are in the Moodle 2-based system here.

Definitely hope to be able to do it in good time for Moodle 2.3 though. I'll try to do it early next month (crises permitting) - feel free to pester me again in that issue if I still don't respond.

ANy news on getting this into the integration stream for Moodle 2.3?

Not as much interest in this, plus there is existing functionality to achieve the same thing, causing debate and not making it a definite. I am prioritising the user conditions issue.

After re-reading the comments I tend to agree with Sam, we shouldn't have two ways to achieve the same goal. It could cause confusion. Making the groupings interface not suck (as Sam put it!) would be a better approach. Maybe there should be a tracker issue for that!?

The conditional plugin idea is great. I created a tracker issue to discuss it's potential progress - http://tracker.moodle.org/browse/MDL-32927

Certainly shouldn't have 2 ways to do exactly the same thing and that's not just about code bloat but usability. Given the conditional activities are now part of moodle I think using this interface to restrict activities by group(s) is a more intuitive way to go.

If the existing groupings code is to be removed then there should definitely be some sort of upgrade from groupings to conditional groups. I assume this would just entail:
1. ascertain if groupings are being used and if so ...
2. turn on conditional activities if not already on;
3. work out what groups are part of the grouping;
4. restrict activities by those groups where applicable;
5. remove groupings

Is there any functionality that would be lost in moving from old system to new? I can't personally think of any.

I agree that this method is more intuitive and keeps all the conditional restrictions in one place. I am only hesitant updating the code with the master branch if it won't get accepted because this can be achieved in groupings (albeit in a cumbersome way). Maybe it can be included, then we can write an upgrade script to convert the current groupings restrictions and change that interface?

The ability to restrict availability of activities/resources to particular groups is desirable: 1. interaction and 2. whether users can see/access the activity.

Groupings does 1 already. Petr is forever telling us that groupings are broken, are a mistake, won't be fixed so a viable alternative for 2 would be good.

If progressed the relationship between groups/groupings/conditional code would need to be managed carefully. There are a lot of legacy grouping sites.

Also I have a nagging doubt that this moves conditionally into the user management arena and that this might cause confusion too.

Groupings have a massive additional benefit you've forgotten about: they are also (perhaps mainly?) used to restrict sets of groups within activities.

For a simplified example, let's say there is a 'tutor groups' grouping and also a 'project groups' grouping. The course has 20 tutors and also has 3 project options, which you choose when you sign up for the course. On the course, we might have a tutor group forum (where you can discuss things with the other people in your tutor group, e.g. most parts of the course that aren't related to the project) and also a project forum (where you can discuss things with EVERYONE who is doing the same forum). On the project forum, because it's set to the project grouping, you only have those 3 choices in the dropdown.

In addition groupings have the advantage that you can reuse them in different activities. For example, let's say you have a grouping that contains 10 groups representing all the tutor groups within a particular course variant (that might be the 'online only' variant, for example, or some option). You might have a couple of activities that you want to restrict to these groups. Under the basic conditional activities thing you need to configure the same 10 groups in both activities. With groupings, you set up your grouping once, then just select it in each activity.

In the OU system we typically have at minimum, uh, I think five or so groupings for course, used for a combination of these purposes (restricting access and also splitting into different sets of groups for particular activities). Groupings are really powerful, probably more people should use them.

tl;dr version of the above - switching to conditional groups would - objectively, not subjectively - be a massive downgrade from the groupings system. Just with a nicer interface for one particular purpose on simple courses. Which is why I think improving the groupings interface might be a better route.

I need to add a 2 cents worth. Groupings is critical. It sadly is being missued (abused) to meet a required need.

Groupings was meant to be for setting up tasks with specific grouping mechanics. i.e.

• This forum is for class discussion. Use class groupings (class A, class B, class C)
• This wiki is for group work in groups of 4 (A1, A2, A3, A4)
• This assignment should be done in pairs
• etc

In this use groupings is vital so that Moodle understands how to apply the specific grouping mechanic needed as set by the teacher.
The "for group members only" means that students not allocated to this task grouping methodology dont see it. And this is valuable.

The issue here of course is that in Moodle there is a STRONG need by facilitators to set activities or resources JUST for a group. 1.e.

• This is a informal homework task for class A
• This is a resource just for external users
• This task is for the January intake only and needs a specific date.
  For the above methodology I would either need to make separate courses (more work for teachers and more confusion for students), or create multiple resources and activities that all students see which also leads to confusion.

So lets reiterate:

Separating by groupings is not designed to be used this way and as such:

• Groupings are a pain to setup. Often today a grouping is created with only one group in it to allow me to separate tasks out as listed above.
• grades still show in the gradebook for items that I may not see in the course
• It is not intuitive as terminology does not make sense when used in this fashion

I am not suggesting the removal of groupings at all and I DONT believe it doubles up on functionality. It is a different tool for a different purpose and with different strengths and weaknesses. It is like saying lets ditch glossary because it double up on the database activity functionality.

Lets instead say "HEY! This is the wrong way to do it. Groupings are for grouping mechanics. As intended. Conditions are about setting conditions for access" When done this way I do not think there is a double up. It is a creation of a new feature that meets the needs of our facilitators.

P.S. Separate issue. If a condition is set (date based, workflow related or through the suggested groups mentality), then these should also not show up in a students gradebook until the criteria is met as set by the teacher.

Julian

As many educators using Moodle find the tracker daunting. I have also started up a discussion on Moodle.org. Will be interesting to see fi there is any traction on the issue.

http://moodle.org/mod/forum/discuss.php?d=202512

JR

Great idea - much needed, but it needs to apply to resources as well as activities.

Hi Ian,

Sorry...should have been more clear.

The "Restrict access" functionality is indeed applied on all Moodle resources and activities. SO this solution would include that option.

Julian

I see that MDL-31510 is now in 2.2.3 fixing that students only see Assignments in the Gradebook based on their Group allocation

@Julian

So this is a proposal to replace the Experimental Available to group members only functionality that restricts avalaibility, not the non-experimental aspect of groupings that manages user interactions with each other.

For information, the OU has been using the 'available to group members only' feature at scale in both 1.9 and 2.x. So turning it on is about as 'experimental' as dropping an apple onto a scientist to find out if gravity works.

It sounds like MDL-31510 might have cleared up the last minor glitch, or are there other issues? If not, it might well be time to remove that option entirely from the interface and code (leaving it 'always on'), I would definitely like to propose that, unfortunately don't have time right now as things are pretty hectic and it probably requires winning an argument with Petr first.

Ok folks, I'm coming at this with a non-tech background, so I apologise if I'm doubling up on anybody's previous comments. I was having a hard time understanding why we may find both ways of doing this useful, when a client put through a support request this morning. Their situation is as follows:

They have a generic base course, and provide international training. So they have common resources and activities, and resources in particular that are intended for only specific countries (as legislation is different in different locations). They also have stand-alone entities in the countries that would like their own private forums - but not every stand-alone entity wants this (or Separate groups would be a viable option).

I advised as follows:

We have separate entities for each of Sydney, Perth, Auckland and Wellington. These entities are in the countries Australia and New Zealand. Sydney and Auckland want their own private forums. Australia has its own set of additional resources, so does New Zealand.

Our structure runs thus: Groups for Sydney, Perth, Auckland, Wellington. Groupings for Australia (containing Sydney and Perth groups), New Zealand (containing Auckland and Wellington groups), Sydney (containing Sydney group) and Auckland (containing Auckland group). Resources for Australia allocated to Australia grouping, for New Zealand allocated to New Zealand grouping. Forums built for each of Sydney and Auckland and allocated to groupings for the same (if we use Separate groups, Perth and Wellington will be able to see a forum they do not want access to).

Its the last step that I find frustrating - having to create a container for a single group just to be able to allocate a specific resource or activity to it. Sam, if I understand correctly, you're saying this rarely occurs at OU, so groupings is fine. Many of the users I work with have a need for this though, and the restricted access to a smaller selection of groups is flexible and readily understandable.

This example however demonstrates how groupings co-exists nicely beside restricted access. When only one or two groups want access to private forums, using restricted access with groups makes sense. When I have many groups from the one location needing access to specific resources, Groupings is a better alternative.

While I understand the idea of avoiding code-bloat, its my understanding that Moodle was built to be simple enough so that teachers without a technical background can use it - and Groupings for allocating to a single group doesn't fit this!

This doesn't have to be an either/or situation. Code bloat to me is including code that is superfluous, not code that adds extra functionality. Restricted access to groups can't provide the bulk management of groups that groupings offers, but neither does Groupings offer an elegant solution to restrict to just one or two groups with ease.

I have asked some of the clients who have experienced difficulties with this to come and comment on this issue, but several have indicated they are a little perplexed at the more technical side of things in tracker I'm hoping this post helps make it simpler - and that by putting my understanding out there, it can be corrected by wiser minds if needed!

I have rebased the code with the current dev branch, tidied it up and fixed a few issues.

Reading all the current points I am thinking that this functionality should be included in core. I respect that this is achievable in groupings, but a lot of the community (as you can see in this tracker issue) want a simpler way of achieving this goal. As Lindy stated - 'Moodle was built to be simple enough so that teachers without a technical background can use it - and Groupings for allocating to a single group doesn't fit this!'. There is the concern about code bloat, but does this warrant not providing a feature popular with the Moodle community?

As I expressed the forum discussion (http://moodle.org/mod/forum/discuss.php?d=202512#p883562) I agree with the need for a solution but am not convinced that this method is the right way to solve the problem. I believe that there is a risk in people getting confused by having two non-exclusive ways to achieve the same outcome.
I would much rather like to see Sam's suggested solution (in forum) get more attention.

Julian,
You're right on the money here; by all means make another option that is simple for the everyday teacher to use/implement. The easier it is to do things within Moodle that actually assist teachers the more they will want to use it- and this is a good example.

Please make this happen as it will make for much more use across our Institute and easy functionality..

Lindy: It is not the case that the OU doesn't often need to restrict things by groupings which are a single group. We do this frequently. However, we do have systems which automatically create these groupings for lots of common cases. In 'less common' cases our system administrators have to go through the easy, but slightly tedious, process to create a new grouping just like everyone else... (And by the way we have a few courses very similar to the one you described.)

There's obviously a lot of discussion about this issue, but nobody has suggested a reason why the approach described in my forum post does not solve the problem in a neater and simpler way - without requiring any back-end changes, and while improving usability of the groupings feature in general e.g. if you want a grouping to separate forum discussions it would work for that too. I have filed a suggestion for this improvement as MDL-33014. I suggest we close this issue and concentrate efforts on that one if desired.

I just posted this in the forum. But as it is a strong element of my case, I want to paraphrase it here as well.

Should not the functionality reside in an "obvious" place?

Forget existing users for a second and put yourself in the place of a new user.

You want to restrict access of a resource to a group. Where do you look?

In a place called "restrict access" which restricts access to material based on a condition, or a place called "grouping" which is about categorising types of groups.

This is my bugbear here. The old way was the only way because we did not have other alternatives. With current methodology it makes no sense to leave it there anymore.

A point was raised that this new methodology only works if Conditions are enabled by Admin. The issue with that statement is that Groupings is also off by default and currently listed as an "experimental" setting scaring many admins from turning it on anyways.

Just because that is how it was done before does not mean it should continue to be done that way.

/me stands ready for the counter to his counter argument

Julian

Definitely all the groups UI (and conditionally allowing access to activities by groups) needs a really good overhaul. Possibly a complete redesign.

I just wanted to say that the forum post intimated this might be possible for 2.3 and there is about as much chance of that as of everyone in the world agreeing on everything. We are already past code freeze and frantically trying to polish what we have. Aim for 2.4 maybe.

Julian: I agree with both your arguments, but they are not arguments for duplicating the groupings back-end functionality. Think about it from the database end: fundamentally, if you want to restrict an activity to people from certain groups, you are going to need a way to link between an activity, and one or more groups. We already have a pair of database tables that do exactly that (no more, no less), it's called groupings.

To put it another way, even if we actually did implement a way to restrict access using the conditional access system instead of using the grouping system, then I think it should work by providing you a dropdown to select a grouping to restrict access to....

A. Regarding the user interface confusion:

• The 'Visible' option is also in the wrong section (it's under 'Common module settings' but it should be under 'Restrict access').
• 'Common module settings' is incidentally a useless heading.

My proposal for this would be something like:

• Add a new section heading 'Groups' which has the group dropdown and/or grouping dropdown (depending on activity features).

• Revise pop-up help for the Grouping dropdown.

It will then be equally logical to have 'restricting access based on group' be in the section headed 'Groups' as it would be to have it in 'Restrict access', and since they're right next to each other, you will probably not fail to spot it.

There are other solutions, for example you could add text inside the restrict access section, or you could actually duplicate the grouping dropdown in both places somehow.

B. Regarding admin settings

I agree that having to turn it on is a red herring (plenty of useful features have to be turned on). The experimental setting is also a red herring. As noted above, I propose removing the 'enablegroupmembersonly' experimental setting, or whatever it's called, entirely, and treating it as if that option is always on (i.e. going from an experimental option to a no-option).

Basically I think there are multiple UI problems here, I already filed one of them as an issue and would encourage others to do the same. I don't think creating two separate backends (with two separate sets of bugs) for the same thing is a good solution to the UI problems, is all

Julian, I'm with you on this one. I can see both points but the other point is coming from the perspective of folks with experience. When I have to instruct my teachers, they are already overwhelmed with everything. I don't need to be adding more complexity. As Julian mentioned, look at it from the point of a beginner. If I, the beginner, have a pdf or a word document that I don't want anyone to see but a specific group, then when I create that pdf or word document I should see, as shown in the group-1.jpg, a place to restrict groups. When you take off your tech shoes and put yourself in the shoes of the common teacher, who is most likely teaching themselves, it's obvious. I don't think Julian is saying to scrap anything else. I'm certainly not. I'm just saying make it easier for everyday teacher out there.

Hi all.
I would like to add a supporting argument to this feature suggestion.
Relying on groupings to restrict access to various groups does not only mean that I have to create a grouping for each group I want to restrict a certain activity/resource to (an annoying extra step) but also that I would need to create a grouping for every Combination of groups I want to restrict the activity to. So if I want activity 1 to show to groups A+B I'd have to create grouping AB, activity 2 to groups A + C I'd build grouping AC, activity 3 to group B+C I'd build grouping BC and so on.
Improving the grouping UI would be treating the symptom while not addressing the real problem which is that restricting by groupings is simply not flexible or powerful enough to allow people to achieve what they need.
Whereas if we have conditions by groups one could either choose multiple groups from a list box or by using and/or conditions - however it is implemented and save a lot of tedious and confusing work.

William - Explain to me why exactly you think it would be hard for teachers to restrict groups according to the interface given in MDL-33014. To restrict groups (using the 'quick grouping' interface described in that bug), you click a button on the activity screen and click to select one or more groups. I don't think there is any way to make that interface any easier...

Amir - (a) Why it is any more tedious to select groups from a list box (after clicking a button to make the list box pop up) as per the interface in MDL-33014, compared to selecting groups from a list box as per the original proposal in this bug? (That was a rhetorical question. The answer is: it isn't.) (b) Yes there are a lot of possible combinations but either way these have to be saved somewhere and it doesn't really matter where - there's no limit on the number of groupings. (c) Using groupings lets you actually reduce those combinations because you can reuse the same complex selection of groups for more than one activity, something which is frequently necessary (if you are making a complex selection of groups in the first place).

Sam,
I haven't yet suggested improvements or ideas for the original idea here, but I can already see a possibility of adding complex conditions related to groups as suggested in profile fields - http://tracker.moodle.org/browse/MDL-29538 - you can potentially have a condition for show an activity for people NOT in a group or NOT in Groups A or B. You might suggest a way for achieving this in groupings by adding some logical AND/NOT/OR mechanisms there, but again to me it feels like stretching groupings to areas it does not fit into, just to make it usable for restricting based on group membership or non-membership.
Also, in the case of restricting for just 1 group, there is still an extra "unnatural"/redundant (in the eyes of the common user) step to add a grouping that holds that single group, even if you do make it faster with your pop up suggestions.
Also consider what happens if I now want to change the activity to show to a different group combination (which still doesn't have a grouping associated with it) - I need to go to the activity, click your suggested pop up, create the new grouping. In this case the previous grouping becomes redundant if I do not use it in other activities.

Here's another use case to exemplify. You create activity 1 for groups A+B (by creating Grouping AB), you than create activities 2 and 3 and restrict those to Grouping AB (obviously, you might do this for more activities).
Then after a while or for whatever reason you decide activity 1 (and this activity alone) should not be for groups A+B but for A+C.
Now 2 things can happen -
i. If you go directly to the groupings screen, you change Grouping AB to include A+C and rename it AC. All of a sudden activities 2+3 are also effected (you might have not noticed or forgot you also restricted them to this grouping, or this was done by another user, or the whole thing of groups and groupings is too confusing to remember it all).
ii. If you go to the activity and try to change it from there you may try to click the grouping add/edit popup, and then do the same mistake as above and effect activities 2+3....

These use cases and similar problems we can try and think of, are again a demonstration of the fact that groupings for activity restriction too limited and is managed separately from where you set the restrictions in the activity.
While grouping may on some occasions save time in recurring combinations, they do this at the expense of flexibility, power and by adding complexity and confusion to users, and opening a place for more errors as described above.

Thanks for responding - these are good points, but I still don't believe they favour this solution.

1) I agree it would not be at all sensible to extend groupings to add boolean logic. However, you can achieve the same sort of thing using an interface like the one I suggested - if you shift-click the entire list to select all of them, then ctrl-click the one you don't want. Not quite the same if more groups are added later, but a perfectly serviceable UI that should handle most requirements (i.e. I don't really think too many people need actual working Boolean logic here).

2) With regard to your long example about the two different activities, I actually think this is an illustration of why groupings are better. For example, you've decided that the user wants to only change one activity. I'll answer that in a minute, but I actually think it's going to be much more common to want to change all three activities, and without using groupings or an effectively identical system, that's going to require manually editing every single one. (For instance, let's say there are eight groups and four of them are doing one project, four doing another project. You set up the activities, but now one of the groups decides to change project.)

3) If you do want to change just one activity out of the three then it is easy with the proposed quick grouping interface (MDL-33014): go to that activity, click the button to create a new grouping, and select the different group(s), then that's it. So you can see that in this proposed situation you have the freedom, using a suitable user interface, to EITHER change all of the activities that you had previously intentionally selected to share the same grouping (using the grouping screen), OR just take the current activity out of that grouping and give it a new group or set of groups.

4) I agree you have identified a problem with the proposal in MDL-33014 which relates to editing the grouping for an activity. As specified, it would let you just create another one, but then you'll end up with millions of unused groupings for the same activity which is a bit silly. (Also, I didn't say how it would determine the name.) I'll edit that issue to add a proposed solution for that.

Hi Sam,

Amir makes my point above. I would need to create many different groups depending on combinations. I'm just saying that when a new teacher creates a document and wants it only for a certain group or groups then it's logical that when they create that document it should be right there for them to make that decision, along with the other restrictions. They shouldn't have to jump through more than one hoop. I'll have to admit that this discussion seems to have a number of different threads being looked at and I'm getting twisted around who's standing up for what. I'm standing up for that new teacher who shows up for work the first day and is told, "You need to create a viable online program for your music class!""It's in your contract!Unable to render embedded object: File (""Go do it) not found.!" with no knowledge of how other than having been told about this program called Moodle. I've seen this happen a number of times in my own school. Let's just keep it simple. And please call me Bill. I need to change my profile

Bill: Thanks for clarifying. Yes, that's exactly what I am proposing in MDL-33014 - that the option to select which groups can access an activity should be 'right there' on the activity settings page.

Basically my position is that there is a user interface problem and we need to improve the interface (which is also what you are saying) but for technical/software quality/maintenance/complexity reasons, the approach in this issue is not a good one, which is why I intend to close it. Hopefully somebody will have time to work on MDL-33014 (or a similar approach) at some point.

Question of importance: Why must we have grouping to restrict access?

This question is key of many parts of the debate here. Why is this the case?

Groupings is menat to be for categorisation of different styles of groups to be used for tasks. grouping in pairs for a task, grouping at a class level, grouping for tutur groups/mentoring. Why is this tied to limiting access at all?

I dont see why we need to create a grouping for a singular group to restrict access. And the suggestion that we allow a grouping to be created automatically does not fix this issue. It is still confusing.

Wouldn't a simple option be to have the restrict to groups or grouping as suggested here. And a link next to it to take them straight to the "groups" setting to create on the fly if need be? Teachers could then choose to limit to a grouping or three individual groups as per existing restrict access methodology.

Secondly, in the real world, we have many instances where we have a specific mix of groups for one task only. Thinking as a teacher, I dont want to have to go through to create a grouping for a one off event. Surely i could then just ad the two grous as options in "restrict access" for that one off event.

I understand your position Sam and even agree that it makes sense to some degree. But I think it fails in real life use. It needs to be faster, more dynamic and easier to access. Groupings, regardless of UI, will never be easy for quick limit to one group or for these one off unique cases.

Julian

I second Julian's previous comment.
Moodle should be intuitive for teachers and their workflow.

Closing this issue because the argument isn't going anywhere and there's no chance this will be implemented. From Julian's last comment:

"I understand your position Sam and even agree that it makes sense to some degree. But I think it fails in real life use. It needs to be faster, more dynamic and easier to access. Groupings, regardless of UI, will never be easy for quick limit to one group or for these one off unique cases."

Again (since I fail to understand how this doesn't get through), here is my proposed interface to restrict an activity to one group, or for a one off unique case:

When editing activity...

1) Click the 'Select one or more groups' button.
2) A list pops up. Select one or more groups in it.
3) Click OK.

Any claim that this interface 'will never be easy' is, in my view, transparently wrong.

How exactly are you going to make it faster - are you going to paint stripes on? More dynamic - perhaps it should bounce around the screen? Easier? Than clicking one button and selecting the groups you need?

What's more the grouping-based interface will work correctly when using group mode whereas the proposal in this bug will have inexplicably poor behaviour in that case. (I.e. if you set up a forum with group mode and you limit to 2 groups, when you do that the correct way - with a grouping - then if you go into that forum the group-select dropdown will only show those groups and not all 20 or whatever. Who's going to expect that?)

Groupings already work; this will never work as well, plus it adds another wodge of code for no reason and creates complexity for users who now have two completely independent methods (a good one and a bad one) to restrict activities to groups.

The interface for setting up groupings is horrid - everybody agrees with that which is why there are so many comments/votes on this bug. I agree too. But this isn't the way to solve the problem.

This is a fascinating post Sam, and an interesting discussion. From my point of view, I like the clear leadership. I will need to Google to find out what Wodge means. It is early here, and I may think differently after morning coffee.

There are scores (hundreds?) of half baked, half finished, insightful (and not si insightful) conversations here on the tracker on what many regard as key issues. Some are issues of bugs. (Like assiognments that are not submitted but say they are, backups that fill up a hard drive) some are functional improvements (like can you create more than on course at a time, can you subscribe at a discussion level, can you self enrol in a group) and some are issues of ongoing useability (like this groups questions). I've had my say elsewhere on our processes (if programmers were to teach one day a month in Moodle we'd see progress, there is not a good process yet for managing developments of functionality, and since one persons vital is another person's optional [we need good processes . . ], have a list of things in train, Moodle is unrealistic to expect many people to use tracker . . ) etc.

So you have led, squashed the request, but where to now? What happens to this conversation? The cynic in me says we have poked, seen a bit of conversation and interaction and things will now settle back to status quo. The next time we do a staff workshop we may get once again a little chagrined by what we are having to say . . The next time we are having to set up a course with 5 groups and some assignment we feel tired. . . Sometimes people will stumble across dusty conversations in the tracker that will result in a post sent out to 21 people most of whom will quickly delete it.

SO: I really think there must be a better and more hopeful way. Maybe the other tracker items will come to something.

-Derek

Sam.
As an addon to Derek's points above-
Even if your decision is the "right" one to make (and apparently according to the established processes, it is in your hand to determine it is), I feel uncomfortable with the way it was made and the way it was conveyed.
Reading the parts of your answers that related to the issues themselves and elaborated the pros and cons of this or that approach, I was actually not certain if the solution you suggested might actually be a satisfactory one. I was expecting this conversation to continue and lead us to a better understanding of each option and a decision based on (dare I say) dialogue.
I appreciate the fact that there are many things to handle in such a massive endouver as Moodle, and that decisions need to be taken in order to focus and move forward. However, I think we (and Moodle) could all benefit from a more open examination of suggestion such as the above, especially considering the impression that at least some of the friends who put their minds into this conversation have some experience with considering from different points of view (and just to make clear - I am not referring to myself but to the other participants).
Personally, the way this ended up makes me feel I would think twice before bothering to discuss what I considering a valuable feature or chane idea as soon as I see this kind of replies. I have had similar thoughts on other tracker issues or forum discussions in Moodle.
I hope you read my comment with understanding that it is all in an attempt to see Moodle continue and improve as I truly care about it and not as a comment directed against you specifically.
Amir

Sam, How about moving this conversation into the Forums, to get more input and insight from the Teachers that are using Moodle daily and the general user community, before closing/resolving this issue?

Derek/Amir/Nadav: I am not the world's most patient person so frankly it is quite surprising I didn't do that rather earlier

There was lots of discussion in this issue but none of it seemed to contradict my opinion that if we had a user interface for selecting groups (while editing activity settings) that wasn't horrible, and used the existing groupings back-end, then this would not even be an issue. Seriously. If MDL-33014 was already done, would anyone have even bothered to propose this? They would not.

Basically all of this is at cross purposes. Lots of people want something done about how it's difficult to restrict an issue to one or more groups. I am not in any way attempting to shut that down. But from a technical perspective the solution proposed in this issue is not a suitable one and would have bad consequences which I explained.

To put this another way:

HOWLING LYNCH MOB, SWINGING BURNING TORCHES AND PITCHFORKS: The usability sucks! The way it looks in this proposal would be much better!

TERRIFIED DEVELOPER, NAILING BOARDS TO WINDOW: You're right, but because of the way it works in the back-end (which by the way, you, lynch-mob, don't in fact really care about) this isn't the solution. Move along please and burn down some other house.

If you are an ordinary user of Moodle and you care about the interface then you should go look at MDL-33014. If that interface sounds like a good one then you should advocate for it - vote for that issue, parade outside Martin's house with banners demanding it, perhaps consider funding Moodle HQ to develop it (do they still do that?), etc. Or if that user interface doesn't sound like a good one, suggest problems with it in that issue, or file another issue if you think something totally different should be done.

I suspect what a lot of people are really thinking is 'oh, somebody actually coded this, whereas nobody's coded anything for MDL-33014 so it might never happen, so this issue is our only chance of getting it in and who cares if some developer thinks it's not the right way to do it'. You may be right but (a) 'actually coding something' is probably only about 20% of the work necessary to finish it for Moodle, and (b) 'somebody's already done the wrong thing, and there's not too much immediate prospect of anyone doing the right thing, so can we include the wrong thing in Moodle please' is a really bad argument.

There, is that enough explanation/sarcasm?

Sam,

I think usability is more than how it looks! I also think a decision shouldn't be based on what is easiest to implement - if there are a lot of steps to get to the desired result then let's make a plan and take the first step.

Why I think the patch is the right thing (and implicitly groupings the wrong thing) I've posted in the forum. And yes, it does contradict your opinion - wouldn't be much of debate if it didn't.

To me it's a simple question: if neither the groupings code nor the patch by Mark existed which of the 2 proposals makes more sense? And along with everyone else here I'm happy if there is some debate (preferably in the forum), and if the consensus is to stick with groupings then so be it. But seems a little early to be shutting everyone down.

And finally my plus one to:
"Moodle should be intuitive for teachers and their workflow."

Shane:

Yes if you plan to replace groupings with this system (i.e. in addition to this patch, add all the code/database changes necessary to remove groupings entirely from Moodle), then from my 'component maintainer' perspective I have no objection whatever.

My objection is that this new backend duplicates all of the existing groupings backend, albeit with slightly less functionality. There are two solutions to the problem: one, don't add this backend, or two, delete the groupings backend and replace it with this one. Either is fine. Having two near-identical backends that do the same thing is not.

However, groupings is a critical feature for a number of users (including, if I put away my 'unbiased code maintainer hat' for a minute, the OU - but by no means only us) so I am certain the 'delete groupings, replace it with this' option won't happen, which is why I closed the issue.

I haven't had time to read the forum thread - sorry.