What I actually want to do is to create ad admin role that restricts a few 'dangerous' things (for example, authentication and enrolment). However, the notes for this role imply that it more-or-less overrides everything. I'm guessing that if I switch it off, it'll totally break the admin role.
I'm trying to avoid loads of experimentation to be honest - does anybody have any more info?
In reply to Howard Miller
Re: What *really* does the moodle/site:doanything role do?
by John Isner -
Howard,
Don't change the Administrator role.
I assume you want to make an Administrator-like role that isn't as powerful as Administrator, and assign this role to other users (the main administrator will retain the Administrator role).
It will be easier to start by creating a new role from scratch (one with all permissions Not set) and build it up with the permissions you want, rather than starting with a copy of Administrator and trying to subtract permissions from it.
Two permissions in the predefined Administrator role are likely to cause the most confusion if you build and test top down: moodle/legacy:admin and moodle/site:doanything. Either of these can occasionally act as a trump card in your deck of permissions, enabling you to do things that your other permissions would normally prevent.
Don't change the Administrator role.
I assume you want to make an Administrator-like role that isn't as powerful as Administrator, and assign this role to other users (the main administrator will retain the Administrator role).
It will be easier to start by creating a new role from scratch (one with all permissions Not set) and build it up with the permissions you want, rather than starting with a copy of Administrator and trying to subtract permissions from it.
Two permissions in the predefined Administrator role are likely to cause the most confusion if you build and test top down: moodle/legacy:admin and moodle/site:doanything. Either of these can occasionally act as a trump card in your deck of permissions, enabling you to do things that your other permissions would normally prevent.
In reply to John Isner
Re: What *really* does the moodle/site:doanything role do?
by Howard Miller -
Am I right in thinking - well, if I was a cynical person anyway - that those roles are there because nobody could think of the "proper" roles for certain activities?
In reply to Howard Miller
Re: What *really* does the moodle/site:doanything role do?
by John Isner -
The design of roles was severely constrained by the need for backward compatibility (enabling users to upgrade smoothly). You probably wouldn't see those two capabilities if the system was designed from scratch.
I think the moodle/site:doanything capability (to give it its right name) is there to stop admins being able to lock themselves out of the system when editing the admin role, and also, so that if you install a plugin where the default permissions defined by the programmer are screwy, then admins can still do anything.
Tim,
If the rationale for moodle/site:doanything is to prevent the admin from locking himself out, then it isn't always working. I know you said "when editing the Administrator role" but one would expect doanything to provide a bigger safety net.
A number of admins have locked themselves out, usually by changing a User policy. If you set the Default role for all users to Student, for example, the administrator won't even be able to log in. Other changes result in the loss of the Site administration block. Could these be the result of a permission calculation that ignores doanything?
I checked the code. Doanything is ignored when calculating permissions for the 25 capabilities listed below (in at least one calculation). The mod and legacy capabilities seem harmless enough, but thinking about some of the others (especially moodle/course:view) makes my brain hurt.
If the rationale for moodle/site:doanything is to prevent the admin from locking himself out, then it isn't always working. I know you said "when editing the Administrator role" but one would expect doanything to provide a bigger safety net.
A number of admins have locked themselves out, usually by changing a User policy. If you set the Default role for all users to Student, for example, the administrator won't even be able to log in. Other changes result in the loss of the Site administration block. Could these be the result of a permission calculation that ignores doanything?
I checked the code. Doanything is ignored when calculating permissions for the 25 capabilities listed below (in at least one calculation). The mod and legacy capabilities seem harmless enough, but thinking about some of the others (especially moodle/course:view) makes my brain hurt.
mod/assignment:submit
mod/chat:readlog
mod/choice:choose
mod/data:manageentries
mod/forum:viewdiscussionsfromallgroups
mod/forum:viewhiddentimeposts
mod/forum:viewqandawithoutposting
mod/glossary:manageentries
mod/quiz:emailconfirmsubmission
mod/quiz:ignoretimelimits
moodle/course:managefiles
moodle/course:view
moodle/course:viewhiddenactivities
moodle/legacy:admin
moodle/legacy:coursecreator
moodle/legacy:editingteacher
moodle/legacy:guest
moodle/legacy:student
moodle/legacy:teacher
moodle/role:unassignself
moodle/site:accessallgroups
moodle/site:doanything
moodle/site:langeditlocal
moodle/site:langeditmaster
moodle/site:mnetlogintoremote
mod/chat:readlog
mod/choice:choose
mod/data:manageentries
mod/forum:viewdiscussionsfromallgroups
mod/forum:viewhiddentimeposts
mod/forum:viewqandawithoutposting
mod/glossary:manageentries
mod/quiz:emailconfirmsubmission
mod/quiz:ignoretimelimits
moodle/course:managefiles
moodle/course:view
moodle/course:viewhiddenactivities
moodle/legacy:admin
moodle/legacy:coursecreator
moodle/legacy:editingteacher
moodle/legacy:guest
moodle/legacy:student
moodle/legacy:teacher
moodle/role:unassignself
moodle/site:accessallgroups
moodle/site:doanything
moodle/site:langeditlocal
moodle/site:langeditmaster
moodle/site:mnetlogintoremote
In reply to John Isner
Re: What *really* does the moodle/site:doanything role do?
by Matthew Davidson -
Our site is also in need of a way to give somebody doanything abilities minus site config and a few other things. This should be dealt with quickly if the code to fix the issue already exists. Please consider this a vote FOR participant control.
In reply to Howard Miller
Re: What *really* does the moodle/site:doanything role do?
by Martín Langhoff -
IMO, doanything is semantically very important for the R&C system. It allows the admin to have a capability without it being assigned explicitly - this is great for code that wants to know "can s/he do X by explicit grant or just because s/he is an admin"?
So for example, to ask about what courses you are a participant in, we ask about course:view. But an admin has course:view everywhere, because of "doanything". If this admin is enrolled in a course as a student, however, in *that* course the course:view is explicit, so you could build a list of "my courses" by asking for 'course:view' without considering 'doanything'.
If you look at get_my_courses() you'll see I've lied, and the current code does something really nasty instead. Because for this to work as I've described, the admin role should only have 'doanything'... it doesn't, and I consider that a 1.7 bug we are burdened with. Not too hard to fix though
So for example, to ask about what courses you are a participant in, we ask about course:view. But an admin has course:view everywhere, because of "doanything". If this admin is enrolled in a course as a student, however, in *that* course the course:view is explicit, so you could build a list of "my courses" by asking for 'course:view' without considering 'doanything'.
If you look at get_my_courses() you'll see I've lied, and the current code does something really nasty instead. Because for this to work as I've described, the admin role should only have 'doanything'... it doesn't, and I consider that a 1.7 bug we are burdened with. Not too hard to fix though
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by John Isner -
Hi Martin,
I followed you up until the last paragraph. Please clarify what you mean by
the admin role should only have 'doanything'
Do you mean the Admin role default permissions should have moodle/site:doanything = Allow and all others Not set?
That would certainly make the role easier to understand
If not, then what do you mean?
I followed you up until the last paragraph. Please clarify what you mean by
the admin role should only have 'doanything'
Do you mean the Admin role default permissions should have moodle/site:doanything = Allow and all others Not set?
That would certainly make the role easier to understand
If not, then what do you mean?
In reply to John Isner
Re: What *really* does the moodle/site:doanything role do?
by Martín Langhoff -
Do you mean the Admin role default permissions should have moodle/site:doanything = Allow and all others Not set?
Exactly. Then you can differentiate "can do because he's magic super-duper-admin" vs "can do because he's somehow involved in this context with an explicit right".
Right now we can't differentiate those (because admin role has most right set to "allow" instead of "not set". And it really hurts -- we have some burdensome and funky workarounds to avoid sending forum emails to admins for example. And to list participants. Lots of those all around Moodle.
If someone could just fix the admin role, then has_capability() starts making sense again, and you can remove a few thousand lines of code that is almost purely working around that.
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by John Isner -
Martin,
Good information. Now I don't feel so bad about being confused.
Good information. Now I don't feel so bad about being confused.
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by Petr Skoda -
my +666 to remove all the other caps from admin role in 2.0, this bugs me since early 1.7 betas 
In reply to Petr Skoda
Re: What *really* does the moodle/site:doanything role do?
by Howard Miller -
It would certainly make more sense....
"You can do anything...... except that other stuff", Eh?
"You can do anything...... except that other stuff", Eh?
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by John Isner -
Martin,
By "removing all capabilities from Administrator except for doanything," I assume you mean making all the Administrator defaults Not set except for doanything.
Or do you literally mean REMOVING the capabilities from the user interface so they can't be changed?
If Administrator is always meant to doanything and all of his other permissions are ignored, then there is a much cleaner solution:
By "removing all capabilities from Administrator except for doanything," I assume you mean making all the Administrator defaults Not set except for doanything.
Or do you literally mean REMOVING the capabilities from the user interface so they can't be changed?
If Administrator is always meant to doanything and all of his other permissions are ignored, then there is a much cleaner solution:
- remove the Administrator role
- eliminate the doanything capability
- code checks if you are the admin user and (if so) lets you do anything
In reply to John Isner
Re: What *really* does the moodle/site:doanything role do?
by Martín Langhoff -
> making all the Administrator defaults Not set except for doanything
Correct. The default admin role should have a single "capability" set to allow: doanything.
> remove the Administrator role
Let's not get carried away
doanything is a (special) capability, and as such it can be granted via roles in limited scopes. You could give a "power-teacher" doanything on his/her course. Or on a subcategory.
The admin acct being magic is what we had pre 1.7 and it's a not an advantage. What we (almost ) have in 1.9 is way superior...
Correct. The default admin role should have a single "capability" set to allow: doanything.
> remove the Administrator role
Let's not get carried away
doanything is a (special) capability, and as such it can be granted via roles in limited scopes. You could give a "power-teacher" doanything on his/her course. Or on a subcategory.
The admin acct being magic is what we had pre 1.7 and it's a not an advantage. What we (almost
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by Lennon Day-Reynolds -
The course:view capability doesn't seem quite right for the test of membership in the course either, though. Many not-quite-admin roles, such as a college registrar, may have the course:view cap set for some context higher than a single course, and yet may not want to receive notification emails, be eligible for group assignment, etc.
I've been experimenting with a patchset I wrote which adds a new core capability, course:participant, and changes the get_user_courses_bycap parameter in the datalib function get_my_courses to use my new capability instead of course:view. The legacy teacher, editingteacher, and student roles have the 'participant' cap set by default, but admins, guests, registrars, etc., do not.
This is especially helpful when using My Moodle or the Courses block, as it means that pseudo-admin accounts no longer see an overwhelming number of courses to which they have some access, but not the full 'doanything' cap set.
I've been experimenting with a patchset I wrote which adds a new core capability, course:participant, and changes the get_user_courses_bycap parameter in the datalib function get_my_courses to use my new capability instead of course:view. The legacy teacher, editingteacher, and student roles have the 'participant' cap set by default, but admins, guests, registrars, etc., do not.
This is especially helpful when using My Moodle or the Courses block, as it means that pseudo-admin accounts no longer see an overwhelming number of courses to which they have some access, but not the full 'doanything' cap set.
In reply to Lennon Day-Reynolds
Re: What *really* does the moodle/site:doanything role do?
by Martín Langhoff -
a patchset I wrote which adds a new core capability, course:participant
If the patch is good, I would happily sponsor inclusion for it - unless this issue is resolved in HEAD already.
Note that I haven't been actively hacking on moodle code the last few months, so you'll want some additional reviewers
In reply to Martín Langhoff
Re: What *really* does the moodle/site:doanything role do?
by Tim Hunt -
We at the OU also thing that a course:participant capability is the logical solution to this problem. Unfortunately, Martin D does not yet agree with us. The other key person to get on board is Petr Skoda. I make sure he sees this thread.