|
[
Permalink
| « Hide
]
Martin Dougiamas added a comment - 05/Mar/07 04:16 PM
Can you hold off on this for a while ... I'm a little concerned about the added complexity for GUI and code and documentation and training ...
As you wish
Sounds interesting (+1) , although I've some "use-related" things to do.
If I would be a "normal" Moodle user, I Think I'll found quite frustrating to go to the module->update page to configure somethings about the module and then, go to the roles/caps page of the module to adjust others. So I would propose to have ALL the settings in the module page, no matter if they are going to be module settings or capability settings. Then, both add and update will perform the required tasks, either in the module or in capabilities. I really think we should follow this behaviour. It will allow teachers to ignore all the underlying structure and will make things consistent, instead of having to know WHERE is every setting and what it means. Ciao sending latest patch, should be production quality:
1/ the safe overrides now share the same configuration matrix with normal overrides + improved description text above I tried the patch and it is really nice to use from the overrides screen. I think it's a great addition. +1 for 1.9.3
Two questions about the admin setup side of it though: 1) Query: If you have override and safeoverride is it exactly the same as having override alone? I assume so. 2) Minor Gui thing: The override and safeoverride are not next to each in the list (sort order?) 3) Major GUI thing: The mix of the matrix and the two override caps is a bit confusing ... since the matrix is there as protection can we not just make at least safeoverride as ALLOW by default for all roles? Then we can be more explicit on the matrix screen about what to do if you want to allow people to override unsafe things. Or perhaps better, can we allow setting of the override/safeoverride cap from the matrix screen (checkboxes under role name on left)? 1/ yes - normal override has higher priority - you need to prohibit both if you want to prevent access completely
2/ going to work on that list ordering too in separate issue 1/ fixed risk definitions in access.php's
2/ added allow override editingteacher -> student, guest and non-editing teacher (new install and 1.6 upgrade) 3/ enabled safeoverride by default for editing teachers 4/ hardcoded exception for course and category delete and reset - these do not have risks, but are not "safe" Expected commit day is Wednesday added new risk RISK_UNSAFEOVERRIDE instead of the hardcoded list
sending latest patch, the safeoverrides cap is not enable by default for any role, I am bit afraid because in might have some unexpected results on existing sites.
RISK_DATALOSS is a better name, thanks Martin!
code in cvs, assigning to Helen, please update docs
I have file a separate issue for docs, closing now
thanks! I took the defaults out of 1.9 again :
Petr, thanks a lot for creating the safe overrides capability
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||