Allow public pages for staff and admins only
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mahara |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
When you use Mahara with a range of different age groups, you may prevent certain ages from creating public pages so that they don't share their pages accidentally with the public, e.g. young children who don't look at the sharing options carefully.
I propose we be more granular in who can create public pages and public profiles on the institution level:
- everyone
- staff and admins only
Ideally, an admin could overwrite the setting for individual "trusted" regular users as well so that they don't need to be given the staff role as that comes with more privileges.
And now it's looking more and more like being able to create other roles and be able to manage permissions more like Moodle manages capabilities...
Curently, roles are hard-coded in Mahara and thus that would need to change first.
| Aaron Wells (u-aaronw) wrote | #1 |
| Kristina Hoeppner (kris-hoeppner) wrote | #2 |
| Andreas Schenkel (andreas-schenkel) wrote | #3 |
I think we could achieve this without implementing a fully granular Moodle-style permissions system (and all the performance hits that come with that).
The implementation would look like this:
1. We change the setting "allow public pages" from a tickbox to a menu labeled "who can create public pages", options "anyone", "admins + staff", "admins", "no one". (Maybe some variant in there for institutional admins & staff as well)
2. We do a similar thing to the existing institution-level "allow public views" setting. The current version of that setting allows public views if the user belongs to *any* institution that allows public views, so we would use similar "any" logic for the new version of the setting.
3. We add a tickbox for "can create public pages" to the user settings page, accessible only to admins (much like the user settings option for setting a user's auth instance). This setting would allow the user to create public pages regardless of any other site or institutional settings (or the spam probation system).
4. We write a function, "can_create_