-
Bug
-
Resolution: Fixed
-
Minor
-
3.3.7, 3.4.4, 3.5.1, 3.6
-
MOODLE_33_STABLE, MOODLE_34_STABLE, MOODLE_35_STABLE, MOODLE_36_STABLE
-
MOODLE_33_STABLE, MOODLE_34_STABLE, MOODLE_35_STABLE
-
MDL-63184-master-2 -
-
GDPR Followup Sprint 1
1) Was looking for some changes when I realized that is_site_dpo(), used widely to decide about which operations are allowed for a dpo is simply calling to get_site_dpos(), that doesn't perform any capability check, just looks for roles based in config value.
IMO, some capability should be checked, not sure if one, multiple, or maybe passed by param, but for sure we cannot decide permissions based solely on roles, capabilities are for that.
2) Tangentially related to that, it's also the fact that, for 1st time in 15 years (since admins and caps were invented), we are specifically/exceptionally denying the access to something to admins, based in some exceptional logic, say "admins can do everything but not tasks associated to POs". I personally find this exception (any in general) bad for the system.
I could agree that they could be warned about proper POs existing and preventing them about that but, still, they should continue doing everything. Of course, IMO. I know it was a decision but really it's killing the previous behavior for nothing. Should we start prohibiting them also to edit the gradebook or creating courses or enroling people or editing profiles? We don't do, why this case is so, so exceptional ?
That is, surely only 1) is a real bug, but the 2) reflexion really makes me not happy. Cannot find a logic justification.
Ciao :.)
- Discovered while testing
-
MDL-62600 Admin is misinformed that there are no data requests
-
- Closed
-