I just noticed that the default role definitions appear to define Prevent for everything that a role can't do. This isn't correct in my opinion; in almost all circumstances, role definitions should leave things they can't do as Inherit.
All of this is in my opinion, but here's my explanation why it should be that way (leaving all role capabilities that aren't Allow as Inherit, and not using Prevent at all).
This doesn't make it any less secure - the default is to not allow something, so if a role doesn't allow it, then it won't be allowed, regardless of whether Prevent is set.
So, this doesn't make any difference when you have only a single role. But when you have two roles it causes unexpected behaviour. For example if you are an admin but also a student/teacher on a course, you would expect to keep admin privileges within that course. Because the student/teacher role sets everything it doesn't do to Prevent, in fact within that course you don't have any admin privileges.
In the role definitions, the only commonly-needed options are Inherit and Allow. (It might be desirable to hide the other options behind an 'Advanced' expand button.) Prohibit is useful only when creating 'banned' roles. Prevent, on the other hand, is rarely useful on this screen and would be used only in roles that are intended to be 'secondary' (applied in addition to existing roles) since prevent stops you doing things that you are allowed to do elsewhere - and if you don't have any other roles then you can't possibly have been allowed to do anything else.
For another example, supposing we want to allow a particular student to moderate all forums on the course, when students don't normally have the capabilities for that. No problem right? We just create a 'moderator' role and set it to Allow those capabilities, then give it to the student on the course. But no! Because the Student role has a Prevent, that cancels out the Allow from the moderator role. So the moderator role will only work when applied in individual forums, which is an unnecessary limitation.
Prevent is of course highly useful in the module overrides screens! But it shouldn't be set for any capabilities in any of the default roles.
--sam
PS There might be cases when you genuinely want to reduce the powers of a particular admin or a particular teacher within a context. For those more unusual cases, you would indeed need to create a role with 'prevent' in [since the 'unassign' proposal, that would allow user roles to be disregarded in certain contexts, wasn't included in the system].
Yeah, that makes sense to me, I'm not sure how those PREVENTS got started, but everyone just copied them after that.
I've filed MDL-6907 to track it.
I've filed MDL-6907 to track it.
Just a quick note... This is a very important point. We just spent three days troubleshooting the roles config for our newly upgraded 1.7 installation. We were using prevent in the guest role for capabilities we don't want guests to do, which seems intuitive btw... but causes major problems if you try to have another higher level role allow that capability with the override matrix.
The fix for us was to change the prevents to inherits (in the guest role).
If I get a chance, I'll update the docs/wiki...
The problem is that the "guest" role is not the guest user. Just a bad choice of a name. "Guest" role is the default role for any registered user. The guest user normally gets that role as well, but this can be tweaked, though I'm not sure how...
In can be tweaked on the admin -> userser -> user policies page, or whatever it is called.