mahara-contributors team mailing list archive

[Gordon McLeod <1169962@xxxxxxxxxxxxxxxxxx>]

Hi Kristina,
Yes - I thought about taking the group out of the default permissions for th epage and adding individual users - time consuming but possible (would be easier if the permission list for the page could be added by csv as course lists are usually available). What I didn't think that would do though is hide the page in the list of group pages - just deny access. I'll have to do some testing around that.
Thanks, Gordon.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contrib members
https://bugs.launchpad.net/bugs/1169962

Title:
  Sub groups with different permission per page

Status in Mahara ePortfolio:
  Triaged

Bug description:
  Enhancement

  An advanced group option that allows the administrator to control
  visibility and editing rights over pages within the group, and to
  assign membership within these pages and sub-groups. Rather than 'all
  or nothing' rights for general users, individuals could have editing
  rights over specific pages or collections within a group. Pages would
  have the optional setting to be invisible to non-members, just as
  groups have at the next level up. This parallels the group
  functionality in Moodle, but is far more versatile due to the creator
  / editor rights that users have on Mahara.

  This would allow the creation of generic group areas, within which you
  could have specific project spaces, but only the students
  collaborating on that project would see the page or collection listed
  (or edit the content).

  As an example from some work I'm developing at the moment:
  Our year course cohorts (~140 students) will be expected to collaborate in answering specific research questions, and we hope to use Mahara for thius activity. From a starting point of having a year group on Mahara for all students, with template pages for students to copy, we would end up with about 18 pages per year MULTIPLIED by the number of groups We would also have all students able to see the work of all other groups. This quickly becomes too unwieldy, so the next option is to break up the year cohort group into one Mahara group per module (6 Mahara groups) each with 3 pages per student 'group' - if there were 10 students per group we would have 42 pages, of which only 3 were relevant to individual students.
  Possible solution 1 - If students only see those pages [within a group] that they are members of in the page list it simplifies student interaction with the group considerably.

  The next option is to instead split the students into groups and then assign pages to those groups. Unfortunately the physical composition of members of the group will vary from module to module - and even from week to week - the same students won't be working together on every project throughout the year - we would have to create 50+ groups per year cohort, which becomes unmanageable, and from the student perspective confusing as they are likely to end up with 50+ groups over the duration of their degree.
  Possible solution 2 - within groups have a sub-group option, where membership is a subset of the main group and content is visible / editable based on settings chosen for that subgroup. Students can be added once to the overarching group, then filtered into subgroups according to the project they are working on at that time. Anything they aren't involved with would be invisible - though pages from the subgroups could be made visible to the entire cohort at a later date.

  Regards, Gordon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1169962/+subscriptions