Moodle

Triage stage 1 - confirmed. I can reproduce the bug. Assigning to myself.

Artem, the "Default grouping" setting seems to be pretty undocumented. The question is, what do you expect when setting the default grouping?

Yes, default grouping doesn't even have a help file. From default grouping I expect default setting for resorces and activities.
But I think that more importantly, what I expect from accessallgroups: ability to work with all groups and all users.

yes, this is how it is supposed to work now. Unfortunately we do not have separate setting for "default grouping on modedit page" and "use grouping on particiaption page". We can not add this in 1.9.6. This might be improved in 2.0, but I think we should first cleanup up the enrolment related settings and then start improving the rest.

User with aceessallgroups can't work with all groups? Where is logic?
And where is documentation on "Default grouping"? Why it work so strange?

Artem, please note "access all groups" does not mean "access all groupings". Anyway, you are right, this needs documentation, adding Helen as a watcher.

>Artem, please note "access all groups" does not mean "access all groupings".

Why?

Groupings are clusters of groups (http://docs.moodle.org/en/Groupings)
If I can access to all groups, why I can't access to all groupings?
And on Participants page groups selector doesn't contain all groups. Which seems that user can't access to all groups...

Artem, I fully understand your feelings. Please, let me try to explain how this is currently implemented.

Firstly, the capability "accessallgroups" means just "If the activity in the Separate groups mode, the user can switch to groups she is not member of". Nothing more, nothing less.
The key idea behind groupings is that you want to restrict access to the content for selected groups only. The course setting "Default grouping" not only sets the selected grouping as the default for the modules. It also restrict access at the participants page (as reported). It is an intended feature so teachers can use as many groups as they want in their activities, while the students can see just some of them at the Participants page.
Note that effective work with groupings often implies users being memebers of several groups. If you do not have such complex set-up, there is an easy workaround for you: Do not set the "Deafult grouping" at the course setting page.

Closing this issue - not a bug

> Firstly, the capability "accessallgroups" means just "If the activity in the Separate groups mode, the user can switch to groups she is not member of". Nothing more, nothing less.

?
http://docs.moodle.org/en/Capabilities/moodle/site:accessallgroups
This allows a user to access all groups in the given context (system, front page, course category or course context), irrespective of what group the user is in or whether they are in a group at all.

> It is an intended feature so teachers can use as many groups as they want in their activities, while the students can see just some of them at the Participants page.
Student usually don't have capability accessallgroups.

I don't propose to interpret Default grouping only as default setting. I propose to take into consideration accessallgroups. If user don't have this capability then it can work only with groups from Default grouping, otherwise it can work with all groups.

Sorry, but it is not first bug, that closed as "This is how it is supposed to work now. We can not change this in 1.9.x. This might be improved in 2.0". Despite the fact that it is fairly easy to implement. It looks like a policy of ignoring. I can understand a lot of work with 2.0. But closing (not moving to 2.0, etc) creates a very bad impression...

I do not understand the question mark - imo the wiki docs says exactly what I do. In the visible groups mode, everybody can access other groups so this capability is simply ignored. It makes sense in Separated group mode only.

The last thing I want to do (or have time to) is making a bad impression or participating in a flame discussion. Once the group/groupings machinery is eventually reviewed, this can be taken into account. The proposal may be to extend the current setting and have two separate fields:
1) Default grouping for new activities
2) Restrict visible groups to grouping

As I said, I understand your point of view. But there is a use case for the current behavior that can't be solved in any other way: if you have a lot groups in the course that are there just for the individual activities, you actually do not want them to be listed at the Participants page. You, on the other hand, can simply achieve your goal by either not setting the default grouping or creating a grouping that covers all participants.
That's why we think this should not be changed. Even users with "accessallgroups" may need a way how to restrict a list of displayed groups. That's it.

Thanks for explanation. Overriding function of Default grouping even for users with "accessallgroups" is very unevident. Really needing help file and documentation. If I had the better English, I would have extended or create Groupings FAQ...