As I understand it, the LEGACY roles and capabilities are on their way to retirement.
I guess that means, that in the future programmers that develop new modules, have to create new capabilities too, as they no longer will be able to use the call "isteacher", "isstudent" and so on? Or do they have to make calls to some of the existing capabilities?
I ask because I would like to have a block similar to the MoodleTxt block. In the documentation I can see that its permission is controlled by the capability "mod/assignment:grade", which I do not think is optimal. Is this the way to handle permissions for third party modules or is there at better solution?
LEGACY roles and capabilities - their retirement and new modules?
by Bente Olsen -
Number of replies: 7
Every module can and should define its own new capabilities, that's how the system is designed.
Developers define new capabilities in db/access.php for each module. Moodle will automatically detect these on installation/upgrade and use these to modify the current roles. This is where the legacy settings are still useful in fact, because they define what the initial settings should be for these new capabilities.
So for example, say you have a "Moodler" role like we have in moodle.org. Essentially this is a student, so it's marked with a Legacy role type of "Student". You could say it's a "Studenty" type of role.
In your new Widget module, there could be a new capability called "mod/widget:manage" that you check before showing the management interface in that module. The definition of it in db/access.php will define certain default settings for students, teachers, etc. Teacher yes, Student no. These get copied into all the site roles by looking for the legacy role type. So the "Moodler" role will get the default settings that the developer defined as being appropriate for students.
Of course, the admin can change or override this to anything they like.
Does that make more sense now?
(We do also use these to provide some backward support for old code that uses the deprecated isteacher() and isstudent() calls. These calls are all being replaced over time, but the legacy capabilities will always be around).
Developers define new capabilities in db/access.php for each module. Moodle will automatically detect these on installation/upgrade and use these to modify the current roles. This is where the legacy settings are still useful in fact, because they define what the initial settings should be for these new capabilities.
So for example, say you have a "Moodler" role like we have in moodle.org. Essentially this is a student, so it's marked with a Legacy role type of "Student". You could say it's a "Studenty" type of role.
In your new Widget module, there could be a new capability called "mod/widget:manage" that you check before showing the management interface in that module. The definition of it in db/access.php will define certain default settings for students, teachers, etc. Teacher yes, Student no. These get copied into all the site roles by looking for the legacy role type. So the "Moodler" role will get the default settings that the developer defined as being appropriate for students.
Of course, the admin can change or override this to anything they like.
Does that make more sense now?
(We do also use these to provide some backward support for old code that uses the deprecated isteacher() and isstudent() calls. These calls are all being replaced over time, but the legacy capabilities will always be around).
"In your new Widget module, there could be a new capability called "mod/widget:manage" that you check before showing the management interface in that module. The definition of it in db/access.php will define certain default settings for students, teachers, etc. Teacher yes, Student no. These get copied into all the site roles by looking for the legacy role type. So the "Moodler" role will get the default settings that the developer defined as being appropriate for students."
The legacy roles are like "role templates" / "preset roles"? A feature that is not just a shadow of the past but has meaningful uses in the present and the future too?
That would clear things up a bit for me as I misunderstood the "legacy" to be along the lines of "deprecated".
About the legacy capabilities: I know that I don't know enough about the architecture, but on the surface it would seem that they are not needed at all? Just the deprecated functions like isadmin() are needed to handle the legacy capabilities? "Admins" would be everybody with a system context capability moodle/site:doanything and so on? What am I missing?
The legacy roles are like "role templates" / "preset roles"? A feature that is not just a shadow of the past but has meaningful uses in the present and the future too?
That would clear things up a bit for me as I misunderstood the "legacy" to be along the lines of "deprecated".
About the legacy capabilities: I know that I don't know enough about the architecture, but on the surface it would seem that they are not needed at all? Just the deprecated functions like isadmin() are needed to handle the legacy capabilities? "Admins" would be everybody with a system context capability moodle/site:doanything and so on? What am I missing?
Every module can and should define its own new capabilities, that's how the system is designed.
Splendid, that fulfills my hopes.Developers define new capabilities in db/access.php for each module. Moodle will automatically detect these on installation/upgrade and use these to modify the current roles. This is where the legacy settings are still useful in fact, because they define what the initial settings should be for these new capabilities.
So due to the legacy role settings you have default roles or role standards. That truly makes sense to me. And that Moodle automatically detect widget specified capabilities and legacy settings and copy them to the present roles is nothing but perfect!So for example (...)
Does that make more sense now?
I even feel able to answer my teacher's questions and I think it helps my work with the translation too. I hope that I will get use of it too for a new function in the future.
Thanks!
Hi Martin,
Your explanation sheds new light on the legacy capabilities. Like the others, I had assumed their use was deprecated and used only in code that has not been fully converted to the roles system, like 3rd party code (and some remaining bits of core code), where their effect is seen in calls to isadmin(), isstudent(), isguest(), etc.
Now I learn that the legacy capabilities are also used as a linkage mechanism, specifically, as a means of propagating default values.
Let me see if I understand your explanation. Here's your hypothetical 'manage' capabilitiy for module widget:
This new capability will be copied into all roles, generally with the value Not set. But because the 'legacy' element has an element for editingteacher and admin, moodle/widget:manage will be inserted into roles containing the legacy capability moodle/legacy:editingteacher or moodle/legacy:admin with value Allow.
Out of the box, the only roles that contain these two legacy capabilities are the predefined roles editingteacher and admin (their shortnames). But if I create a new role, say by copying the predefined editingteacher role, it will include the capability moodle/legacy:editingteacher, and so my new role will have its moodle/widget:manage capability with default value Allow.
To summarize, legacy capabilities are used for two completely different things:
Re (2): The legacy capabilities are like recessive genes that are being passed into the DNA of every new generation. Thought experiment: What would it be like if we didn't have (2)?
Your explanation sheds new light on the legacy capabilities. Like the others, I had assumed their use was deprecated and used only in code that has not been fully converted to the roles system, like 3rd party code (and some remaining bits of core code), where their effect is seen in calls to isadmin(), isstudent(), isguest(), etc.
Now I learn that the legacy capabilities are also used as a linkage mechanism, specifically, as a means of propagating default values.
Let me see if I understand your explanation. Here's your hypothetical 'manage' capabilitiy for module widget:
533 'moodle/widget:manage' => array( 534 535 'riskbitmask' => RISK_XSS, 536 537 'captype' => 'write', 538 'contextlevel' => CONTEXT_COURSE, 539 'legacy' => array( 540 'editingteacher' => CAP_ALLOW, 541 'admin' => CAP_ALLOW 542 ) 543 ),
This new capability will be copied into all roles, generally with the value Not set. But because the 'legacy' element has an element for editingteacher and admin, moodle/widget:manage will be inserted into roles containing the legacy capability moodle/legacy:editingteacher or moodle/legacy:admin with value Allow.
Out of the box, the only roles that contain these two legacy capabilities are the predefined roles editingteacher and admin (their shortnames). But if I create a new role, say by copying the predefined editingteacher role, it will include the capability moodle/legacy:editingteacher, and so my new role will have its moodle/widget:manage capability with default value Allow.
To summarize, legacy capabilities are used for two completely different things:
(1) to support legacy code -- code that still relies on the old calls isadmin() isguest(), etc. The use of legacy capabilities in this way is deprecated.
(2) to propagate default capability values into 'families' of roles, i.e., roles sharing a common marker. This use is not deprecated.
(2) to propagate default capability values into 'families' of roles, i.e., roles sharing a common marker. This use is not deprecated.
Re (2): The legacy capabilities are like recessive genes that are being passed into the DNA of every new generation. Thought experiment: What would it be like if we didn't have (2)?
It is quite unfortunate that two different things are called "legacy". And not even quite properly called so.
http://moodle.org/mod/forum/discuss.php?d=86926
http://moodle.org/mod/forum/discuss.php?d=86926
Robert,
In that discussion, people were trying to sort out whether legacy role and predefined role were the same thing. We concluded they were different, and I think Martin's explanation above doesn't contradict that. Unfortunately, the shortnames of the predefined roles and the names of the legacy capabilities are identical (e.g., admin and editingteacher), which has fueled the confusion. But as I understand Martin's explanation, default propagation is not something specific to the predefined roles; it affects any role that has been "marked" with the coresponding legacy capability. Of course initially, these are the predefined roles
If we want to take a predefined role out of the "default propagation" game, we can do it simply by removing the legacy capability. Suppose we set Legacy role type = None in the predefined Teacher role. If we later add the widget:manage capability, the default value Allow won't propagate to Teacher (the value in Teacher will be Not set). I'm trying to understand how much of an impact this would have, if any.
In that discussion, people were trying to sort out whether legacy role and predefined role were the same thing. We concluded they were different, and I think Martin's explanation above doesn't contradict that. Unfortunately, the shortnames of the predefined roles and the names of the legacy capabilities are identical (e.g., admin and editingteacher), which has fueled the confusion. But as I understand Martin's explanation, default propagation is not something specific to the predefined roles; it affects any role that has been "marked" with the coresponding legacy capability. Of course initially, these are the predefined roles
If we want to take a predefined role out of the "default propagation" game, we can do it simply by removing the legacy capability. Suppose we set Legacy role type = None in the predefined Teacher role. If we later add the widget:manage capability, the default value Allow won't propagate to Teacher (the value in Teacher will be Not set). I'm trying to understand how much of an impact this would have, if any.
In reply to Bente Olsen
Re: LEGACY roles and capabilities - their retirement and new modules?
by Greg J Preece -
In truth, I used that capability because it was common across the preset teachers and assistants that would be using the block, and I wasn't familiar enough yet with the capabilities system. (Ignorance or laziness, I can't remember.) In any event, I will follow this thread and rectify the mistake in a future release of moodletxt. Thanks for this thread - very useful.