Details
Bug
Major
Description
A course has one group of students
Course settnigs: Group mode: Visible, Force No
Group toggle icon is visible for activities and changes state (visually at least when clicked)
In either a new or existng assignment (probably others too) Group mode is No or Yes
There is no way to change the group mode other than select No or Yes. If Yes is selected there is no way of knowing if this is setting Visible or Seperate group mode for that activity.
Also just noticed that if Course settings are set to Sepaerate and Force=Yes, it is possible to select No for group mode in the activity settings. If one does this, the group mode icon on the course page still reflects the forced group mode setting for the course.
Issue Links
| This issue is a clone of: | ||||
| MDL-8564 | Groups not working when viewing quiz reports |
|
|
|
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Hi, just one personal opinion:
Once more, I think that all those settings, based on capabilities" should be handled directly from the activity configuration interface, i.e. in the forum/chat/assignment.... mod forms, teachers should see the 3 options (no, separate, visible) and use that interface, with help files and so on, to define their group mode. Then, the corresponding add/update module should perform the required actions, adding/deleting capabilities/overrides or whatever is necessary.
I find (and I guess 99% of users too) it really more usable/consistent than adding, saving, updating, going to overrides and saving.
And this is a general thought not only about groups and their way to be configured but to ALL the settings that, being activity based, rely on internal use of capabilities/overrides. Let's do that easy for moodlers!
Ciao 
+1 for that view point.
The only reason I din't mention it was I'd made the assumption this was a deliberate design decision which was too far along to change (wish I'd spotted this earlier 
).
The current i.e. up to 1.7 approach makes sense imo and works fine as far as I can see.
Something that occurs to me too is that changing things here means that anyone with access to activity settings also must be granted permission to overide roles.
Given the nature of users who are likely to be creating/editng activities this may not present a problem in practice that often, but creating a dependency here (and elsewhere - ref. Eloy's post) doesn't seem the best idea in the world.
).
The current i.e. up to 1.7 approach makes sense imo and works fine as far as I can see.
Something that occurs to me too is that changing things here means that anyone with access to activity settings also must be granted permission to overide roles.
Given the nature of users who are likely to be creating/editng activities this may not present a problem in practice that often, but creating a dependency here (and elsewhere - ref. Eloy's post) doesn't seem the best idea in the world. 
It has been suggested elsewhere:
"I think group mode YES + allow accessallgroups capability = visible groups. Group mode YES + prevent/prohibit accessallgroups capability = separate groups. group mode NO = no group. So an activity set up using group mode can be a separate groups activity or a visible groups activity, depending on the user capabilities."
However, this seems at odds with the commentary in moodledocs: http://docs.moodle.org/en/Capabilities/moodle/site:accessallgroups
"This (accessallgroups capability) allows a user to access all groups in the given context, regardless of the group mode.
For example, a user with this capability set can browse forum posting of other groups when group mode of the forum activity is set to SEPARATE_GROUPS. "
I must confess that I haven't checked this out but the above reads to me like this does not seem quite the same thing as the behaviour described in the "Group mode" help file:
" * No groups - there are no sub groups, everyone is part of one big community