Moodle

I do not feel as strongly as John about this, but it would be better, I think, if the default were not set to "Allow."

Hey Art, You bet I feel strongly about this!

We would like the option of granting this to trained instructors rather than making it default.

Assigning to martin, because he wanted it enabled by default

Please note that many existing sites 1.7-1.9 do not have the ticks in matrix for overrides for teacher role, the safeoverrides will not be fully enabled then. Only new installs or sites upgrading from 1.6 have this fully enabled. Also the list of overridable capabilities was significantly improved, I hope it will be much easier to use now.

In any case there is still time to change the default until Wednesday before the weeklies get tagged and 1.9.3 will be released not sooner than next month.

Dear John Ishner, instead of shouting here you could think about ways to improve this, such as writing upgrade notes for weeklies or you could propose to limit the list of overridable capabilities. I am sure there are many ways to improve this. Sorry, your attitude does not motivate me at all to work more on this

Hey, hey, hey!

Please John. That "worst decision" phrase... do we need to fell so strongly? Really? I don't think so.

All you comments, bugs and opinions are welcome, of course. We are collaborating here. Just that. TIA!

About the comment itself I'd vote for being restrictive as you propose, although, in the other side.. I shouldn't be dangerous to allow "safeoverrides" (at least those that are "configuration settings").

Perhaps we need to split all those capabilities into:

• configuration settings
• safe (from a security pointo of view) overrides.
• risky overrides.

So really I don't know what to vote.... sorry.

Ciao

The major issue here is not the risk or lack thereof in what permissions can be overridden.

It is the lack of training risk.

How many teachers know what a capability is? How many teachers can read and understand the description links in the docs? How many teachers know the meaning of "Inherit" and what the highlighted radio buttons mean? 95% of the PHM's in moodle.org cannot answer these questions. And we expect teachers to? Without training? Just "poof" and they can now override?

IMO we should let site administrators decide what is best for teachers, not moodle.com. Make the default Not set, and let the administrators change it to Allow if they are foolish enough to do so. Smart administrators can be selective in allowing teachers to override (or safeoverride).

To me, this fix seems like an end-run around administrators, and it is asking for trouble.

I see your point about teacher not knowing about capabilities. That's the reason originally I was inclined to vote positively here.

But, in the other side... before Moodle 1.7 (and along 1.8 and 1.9), more and more (module mainly) configuration settings have become capabilities. This means that teachers were able to "adjust" the behaviour of modules in a way they cannot now (if we prevent them to override those "configuration settings capabilities"). That was the reason I suggested about the 3-ways splitting, leaving:

• override of configuration settings = allowed
• safe overrides = not allowed
• overrides = not allowed

FYC. Ciao

As far as I know, forums are the only activity where settings were replaced by permissions. But consider the new "settings interface" (see screenshot).

Many teachers are already confused with they see the Assign roles link in their course administration block. Where is the Teacher and Student link? Wait until they see the new, improved forum settings!

Surely we can think of more creative ways of giving teachers control over forum settings than forcing them to fiddle with permissions.

The new forum settings interface

John, this was totally my final decision, and based on previous discussions where editing teachers have said that that they didn't like the way important settings disappeared from Moodle 1.6 when we added the roles. Forums being the main one as you pointed out but there are others like Database and Course settings I think.

I've always seen that as a very big upgrade bug that we needed to fix. It was a backward step from what we had, and we lost a lot of our "social constructionist" flavor on those sites that didn't even realise the features were still there.

The rationalisation for it before was always security, but now with safeoverrides that is no longer a concern. The fix only applies to those upgrading from 1.6 and those installing new with 1.9.3 so no-one is suddenly going to get a surprise.

Frankly, we do let administrators decide - the same settings screen exists and administrators can turn it off for editing teachers if they want to. The same argument applies WHATEVER default we choose. Perhaps we should alert administrators about this issue during the install - I'd like ideas on the best way to do this.

The override page is not as evil as you're making out here ... there are help links from the page, there are descriptions on the page, it's standard across every part of the system, it just takes a little getting used to. Overriding things on a module level is much less complex than what an administrator needs to learn to use/create/override roles across a whole site. If teachers don't feel able to use it, no-one is forcing them.

On balance, in this case I feel sure it makes good sense to default with these (now safe) tools in the hands of teachers, to at least give them a chance to learn what is possible.

I really thought this was an obvious fix to a bug, but there's a discussion here where we can look more deeply into it and reverse the default if necessary http://moodle.org/mod/forum/discuss.php?d=102042

In addition to making the default Not set, I think "safeoverride" should by default be restricted to module and resource contexts. This would solve the "settings" problem in forums, glossaries, and databases without exposing teachers to the long list of (so-called) riskless permissions at course level, many of which are irrelevant there (e.g., delete courses).

Automatic masking of permissions based purely on the risk bit mask is inflexible and will lead to "risk creep" as new risks are identified. The administrator should be able to define the mask. Imagine a sixth column of radio buttons in Site administration -> Users -> Permissions -> Defined roles -> Manage roles tab interface

Not set..........Allow..........Prevent..........Prohibit..........Risks..........Mask

By default, the radio buttons in the Mask column are clicked for all permissions having a non-zero risk bit mask. The administrator can mask additional permissions by clicking additional radio buttons in the Mask column. He can also unmask permissions. This gives total control back to the administrator, which is where it belongs.

OK, I've reversed this default on Moodle 1.9.3 (for ever) and HEAD (for now). No weeklies contained the new default.

I really want to push for this default in Moodle 2.0 though, assuming that the roles interface will be made sufficiently informative and non-scary.

To be closed once the documentation is updated.

Thanks for everyone's participation (comments, voting etc)