Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.9.3, 3.0
-
MOODLE_29_STABLE, MOODLE_30_STABLE
-
MOODLE_30_STABLE, MOODLE_31_STABLE
-
MDL-52105-master -
-
3.2 Sprint 4
Description
Raised by timhunt in the developers chat, it seems that an "incorrect" CAP_PROHIBIT was introduced by MDL-26017, for managers, on 'enrol/self:holdkey', apparently with the wrong assumption of managers being displayed always as key holders.
I've had not time to verify this... but unless I'm wrong:
1) There was not need to set such prohibit @ system level at all. Blank (not set) was enough. Not sure if that came from the old days where admins were returned always or what.
2) That prohibit effectively prevents any manager to be a key holder ever (prohibit always wins). And that seems to be an incorrect restriction, in fact can imagine sites assigning manager roles wanting to be also key-holders, it's not crazy at all.
So this is about to:
a) confirm that it's not needed to have such system level prohibit and verify key-holders functionality works perfectly without it.
b) confirm that managers are allowed to be key-holders.
c) hopefully covered with acceptance tests.
For your consideration, ciao
Attachments
Issue Links
- has been marked as being related by
-
MDL-26017 Keyholder role 2.0x
-
- Closed
-