Uploaded image for project: 'Plugins'
  1. Plugins
  2. CONTRIB-3367

Groups functionality (menu, see all group meetings, align ability to see meetings with standard moodle behaviour) (solution provided)



    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 1.9.16
    • None
    • Module: Adobeconnect
    • None
    • Adobe Connect 8
      adobeconnect module 2011072100


      Description of the issue
      1. In group mode, wrong group selector menu used. Only shows up if there is a default groupmode at the COURSE level (instead of activity level). This can result in teachers having no way to move between groups. Also, it creates problems when you are using groupings (see CONTRIB-3366) because it will display all of the course's groups, not just the groups in the specified grouping for the activity.
      2. "Current" Group ID being set arbitrarily by hand if it's not set in the URL. The module is not using the 'activegroup' session variable, so it won't remember what your selected group is
      3. Teachers cannot see group activities if they are not enrolled in the group. So if a teacher created the activity, and another teacher tries to access it they will get a "you must be enrolled in a group" error message. This is not standard Moodle behaviour.
      4. Students cannot see other groups' activities, even when groupmode == VISIBLEGROUPS
      5. "All participants" option in groups menu (when has moodle/site:accessallgroups capability, or groupmode == VISIBLEGROUPS) has no effect - it just shows one entry
      6. When you try to access a group meeting that does not exist the meeting info page shows information on the first meeting returned from the server (ORDER BY name ASC). An example of this is in point #1: activity created in grouping mode (only creates meetings for that grouping's groups) but menu selector shows all course groups. Selecting one of the groups not in the specified grouping for the activity will display the first meeting returned from the server.

      Expected Behaviour
      1. A group selector menu should always display if the meeting was created in group mode (regardless of the default group mode of the site)
      2. It should remember active group ID. It shouldn't force an arbitrary group ID from the index page
      3. Teachers (or rather anyone with the 'moodle/site:accessallgroups' permission) should be able to see all group activities
      4. Students should be able to see other groups' activities when groupmode == VISIBLEGROUPS (but can only join if the meeting is public and even then, they will be a guest participant, even if they have a presenter role at the activity context (so that they can be presenters in their own group meeting for example). If the meeting is private, they won't even see a "Join" button (if they did, join.php would simply not let them enter anyway).
      5. It should show a list of all group activities on the same page
      6. It should show an error message saying that no such meeting exists

      1. Use groups_get_activity_group()
      2. Use groups_get_activity_group()
      3. Honour 'moodle/site:accessallgroups' capability
      4. Take groupmode & visibility of course into account (not just group membership)
      5. Loop through array of allowed groups
      6. Check for $scoid in returned array of meeting objects rather than using current()

      Patch needs to be applied AFTER patch from CONTRIB-3302 - it indents a large section of code, part of which was modified in said patch). I did a diff of (MOODLE_19_STABLE + CONTRIB-3302) and (These changes) to make this patch.


      • A lot of the patch size is due to indentation from the loop-through (#5)
      • If you are seeing all meetings on one page, you get "assign roles" button for each group. The button passes the groupID to assign.php but it just seems to hook into the normal edit activity > Locally assigned roles functionality. I don't know what the button is doing there. It makes it look like you can assign roles at the 'group' context whereas in reality, groups are themselves a way of getting more fine-grained control of access permissions in the activity context. If you assign roles from that button under one group and then go to another group, you will see that the roles you seemingly assigned in the other group carried across.

      Patch and github repo
      Links to be provided in comments section once I get a tracker number for this issue


        Issue Links



              adelamarre Akin Delamarre
              jedmondson Jennifer Edmondson
              Akin Delamarre
              0 Vote for this issue
              1 Start watching this issue