Is this the case?
Is this the case?
It was easier when it said something like "Enable groupings". I'm not entirely sure what "group members only" means.
The restricting of access based on group membership is a different experimental feature.
Correct me if I'm wrong. The only way to restrict access to an activity (i.e. some users do not see it at all) is to select a particular grouping. Only people in the grouping see it. To everybody else, it is invisible.
Surely 'group members only' should actually be 'grouping members only' because (in resources anyway) that allows grouping to work (not groups - I think)
- the 'available for groups only' feature IS only attached to groupings not groups. Petr's answer is correct but unhelpful *especially* if you are coming from 1.9.
- I think we might be forgetting the useful feature of being able to hide a resource (or an activity, but especially a resource) based on what grouping it is. In this case the current description makes even less sense.
- The feature being attached to Groupings is a bit spurious. It would all make more sense if it was attached to groups or groupings. That is you could choose a single group to stand for a grouping.
I think your conception of the feature is fairly similar to what grouping does. If I understand you correctly you would like to see in the resource/activity settings form a multiple-selection dropdown (or better an ajax dialogue) with all the available groups to allow you to select the desired groups for that activity/resource and then tick the available to these groups only. This is almost exactly what grouping does. It has the advantage of being more convenient to the activity creator in the context of a particular activity. But the grouping has the advantage of giving a label to a particular subset of groups which you could use in other activities to make the set up of those other activities more efficient.
So, perhaps improving the ui of groups and grouping definition and allowing access to their index pages without leaving the resource/activity settings form would do the trick.
As an aside, and interesting effect of the available for group members only is that you can hide resources/activities from participants who do not belong to any group and so you can hide resources/activities even if you don't have any groups or groupings in the course.
I'm concentrating on the feature to only display the resource or activity to those in selected grouping. This is a surprisingly useful feature but I suspect that very few know about it.
My 'complaints' are really like this...
* to have this feature applying to Groupings in the first place is strange. For small courses it would make just as much sense - possibly more sense - to be able to say 'make this resource only visible to people in this group'. The use of the grouping is either an nice to have or an irrelevance depending on your viewpoint.
* If it has to apply to Groupings then I don't see how or why anybody would know to look for it there. To have the option that enables it with the wrong wording (it says Groups not Groupings) makes that even worse.
Maybe I'm being terribly pedantic but I hate to see useful features lost because we can't word them properly or provide straightforward help.
"Available to group members only" works even without groupings, imagine you have only one group in course - then if you enable this experimental "group members only" feature only people that are members of that group can see/access it. If you have multiple groups in a course and you enable it then members of any group can access it - that is where the name of this feature is coming from.
Now back to groupings - it is simply a subset of groups in a course - nothing else, it can be used for different purposes, unfortunately there are not many useful group features in current activities and even less at the course level - forum group mode, assignment group mode, data module group mode, gradebook group mode, participants group separation, etc.
There is absolutely no feature loss - it is just not fully implemented and there are problems we do not know how to solve - that is why the "group members only" feature is marked as experimental and as such is disabled by default...
I want a **resource** to only be visible to certain people in a course. That's what I want to do and it's been possible (although, granted, experimental) for years.
1. Switch on the confusingly named option "Available to group members only" in the experimental settings.
2. Find a course
3. Create a group
4. Add a resource - a simple url resource will do
5. Tick 'available for group members only'
Now explain to me how this 'works without groupings'?? Unless I have really gone crazy, you can't make group settings for a URL resource (or any resource). You *can* assign a Grouping to the resource and (as far as I can see) the *only* reason to do that is to use this feature (it's even greyed out unless you tick it).
The behaviour of this option seems different between resources and activities and I suppose this is my point. I think what is being missed is that this is actually a useful feature for resources and gets asked for a lot.
What is it I don't understand? I'm NOT talking about activities, I'm talking about the behaviour in RESOURCES.
OK... I've been following this with interest as I recently found that an upgrade from 2.0 to 2.1 meant I no longer knew how to make a resource available only to a particular set of people in a course.
Petr, you say 'please at least do not call it groupings', but what are we meant to refer to when that was in fact the name given to this feature that people have been using?
In 2.0 you could 'simply' (I use the term loosely) create a group, then a grouping and then go to the advanced module settings of a resource and set it so that ONLY a particular grouping could view the resource whilst to the rest of the course students/participants, the resource was invisible. It was a brilliant feature. I often design courses where pupils and parents need to see different information in a course, yet not be aware of this OR where different clients (eg. 02, Orange, Vodafone) need to have the same course for training, but will need different specific resources for their own company.
It WAS called groupings and it worked a treat once you got your head around it. So... seriously, now what? It's been changed and convulted in description and explanation to the point where even the developer is asking you don't call it by it's original name?
If you could just explain how one accompishes this now that would be fabulous.
I find this discussion amazing on multiple levels:
- Its nearly an exact duplicate of the discussion we had with Petr after we proposed implementing auto-grouping creation (whenever a group is created a same-named grouping is created, cutting out that step) - MDL-28082. NOTE: we've since expanded it to include auto-creation of groups and groupings for child courses of meta-courses.
- And it comes with nearly the exact "resolution" -- "nobody understands what groupings are for -- groupings/ available to group members only is broken and can't be fixed". This appears to be an acceptable declaration for some, though most, I feel would likely deduce that anything is fixable given the desire and skill. The skill is obviously present here.
- An incredibly useful piece of functionality is marginalized as "experimental, shouldn't have ever been done". To what end doth one develop functionality? Do we not wish to provide the users with what they need to more easily present their course material?
I entirely understand that resources are finite and this feature seems to have gone on the "who cares" pile with little or no discussion. Certainly not any that I have observed.
I can also understand why Petr complains that resource/activity hiding should not be a side effect of Groupings. He's right! That's incredibly arbitrary and confusing. What we need is a way to do it that works and doesn't break the Gradebook (more?).
I can certainly organise some effort on this but Petr saying he doesn't know how to fix this (whatever it is that needs fixing) makes me a bit uneasy.
The problem - to my mind - is that "grouping" is a really stupid name for the functionality. It's a shame that it wasn't simply implemented as a special form of group (a group can contain either users or other groups). The hiding feature could then have been applied to any group in the course.
It doesn't really matter how stupid or smart the name grouping is. There still need to be some distinction or the whole groups mode should be redesigned.
Suppose for example that you have work groups A, B, C and some activities a, b, c set to separate or visible groups so that each group would have its own work space in the activity. Now you want to add a resource and make it available only to certain users which do not constitue a work group. If we use groups for this kind of filtering and you create group D for this purpose, and there is no distinction, group D will be listed as a work group inside activities a, b, c although it is not a work group and should not be there.
As I understand it, it can't be simply implemented as a special form of group unless 'a special form of group' is really just another name for the funcitonality which is currently called 'grouping' in which case problem not solved.
But I definitely agree that the handling visibility and access to resources/activities should be revisited.
What most people do is to great groups and then create a Grouping per group (i.e. each grouping has one group in it) in order to use this function. This is a complete waste of time.
In the case of Resources, this is completely fixed just by making the current 'Grouping' drop-down (which has no function other than hiding, remember) show both Groups and Groupings.
I have yet to see anybody using this hiding feature for Activities although I suppose some do. I have actually yet to see anybody using Groupings for anything other than hiding activities although, again, I'm sure some will.
It's a classic bit of poor design and I've probably ranted far too much about it.
Howard, if you'd like your users to just be able to create groups and then use those groups to restrict access, check out our "autogroupings" patch posted here: http://tracker.moodle.org/browse/MDL-28082 . It automatically creates a grouping every time a group is created.
I understand that this is not the intended use of groupings, but it's something many of us have come to rely on heavily.
Just happened upon this discussion while trying to work out how to make a Resource (Page) visible to only one Grouping (containing one Group) in Moodle 2.2.
Good discussion, albeit with a fair bit of early confusion.
It seems very clear however, that if one can make an Activity available to a selected Grouping, then this same capability should be available for a Resource (Label, Page, URL, etc.)
I'm not a developer, but having this capability for a static Resource should be as easy (or easier) than applying it to dynamic content such as Assignments and Quizzes.
For Teachers, the actual process of making Activities and/or Resources available/unavailable for Groupings should be achieved in the same way.
Certainly happy to vote for resolution to this, as it is a very useful piece of functionality, and potentially a hugely powerful aspect of Moodle course design
Thanks for articulating this so well. We have many users that want to restrict a particular resource to a given subset of course participants. Call it what you will, that is a feature that is highly coveted.
So, since I am using 2.1.7, I am assuming this all applies: I cannot restrict access to individual resources by group/grouping, or in any other way?
If I hide a resource, it is hidden to all students enrolled in the course, correct?
The only way to restrict access is to do it on the course level by group/grouping? If so, how do I do that?
I realize you are going to tell me upgrade, but that is impossible. I have only begun learning Moodle last week so please bear with me.