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 _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
