Questions about how roles/capabilities are stored in the db

Questions about how roles/capabilities are stored in the db

by John Papaioannou -
Number of replies: 3
A couple quick questions for anyone who knows more than me... I 'd be very grateful for an answer. smile

  1. In the db table "mdl_capabilities", is the "contextlevel" column there purely so that the UI can know if it's meaningful to assign this capability at that level?
  2. In table "mdl_role_capabilities", why are all capabilities assigned at contextid = 1, which is the default CONTEXT_SYSTEM level context? If the capabilities are supposed to be "assignable" (by assigning a role) to any context, then what is the purpose of this column? In my database there is no row with contextid != 1, even though I have a teacher in a course somewhere (and that teacher has elevated capabilities in the context of that course). Why is contextid there at all?
  3. Is "mdl_role_capabilities" generated purely by the information in /lib/db/access.php? How can I force a repopulation of that table? I tried tweaking access.php for a capability with component = "moodle" and bumping the version inside /version.php, but although Moodle did an upgrade I didn't see a change in that table.
Specifically, by answering question 3 I believe we can get a bugfix to MDL-7939 (critical priority, affects 1.7 [and onwards???]).

Cheers
Jon


PS: And since we 're here... what's "modifierid" in that table? Thanks!
Average of ratings: -
In reply to John Papaioannou

Re: Questions about how roles/capabilities are stored in the db

by Yu Zhang -
Hi Jon,

1) Yes I believe so.
2) Capabilities have to be attached to roles. When you create a role, there are capabilities attached to it, and these are automatically assigned to the CONTEXT_SYSTEM context. However there is another part in the roles system called "overrides", which makes use the roles_capabilities table as well. For instance, I can say users with the student role (roleid = 5) can not reply to posts in this forum forum (mod/forum:replyposts) in this forum (contextid = 123). Then you would have an entry with a contextid != 1
3) No, see 2). To insert overrides, you can click the tab that says "role overrides" when you access the "assign roles" interface. To change base role definitions (i.e. role_capabilities assigned at contextid=1), you can use the manage roles interface to edit directly. When you bump up the version of moodle the content in each access.php will get read, and compared against the values in mdl_capabilities table. However, if you just change the basic definitions for legacy roles, (e.g. a capability from CAP_PREVENT to CAP_ALLOW such as the one in the bug), I do not believe it will get picked up. This is not possible to do because such an upgrade will change how existing moodle sites function, and the behaviour might be unwanted.

Modifierid should be the last userid who edited the capability, not sure where it is used, though.

Cheers,

Yu

In reply to Yu Zhang

Re: Questions about how roles/capabilities are stored in the db

by John Papaioannou -
Thanks a lot Yu! I think I 've got a good enough understanding of it now. I 'll try to see how the bug can be fixed... not sure if it can be fixed with the existing infrastructure, actually.

Jon
In reply to John Papaioannou

Re: Questions about how roles/capabilities are stored in the db

by André Martins -

Hello Jon!

I had the same problem you did so I decided to look into the code and see if I could do something to correct the problem. I left a patch proposal that I believe can help you smile (and hopefully others as well).

For your reference (but mostly for anybody else that might not be in context) I'm talking about bug MDL- 7939 and the proposed patch is here and the suggested instructions are here.

I'm not any sort of Moodle expert smile but I tested the patch quite thoroughly and I believe in it enough to leave it deployed on the university campus server that I currently manage wink

Best regards,

  André