Legacy roles vs ???

Legacy roles vs ???

by Mark Cornwell -
Number of replies: 5

Hi,

I had a moodle 1.7 installation and didn't do much with it. In readiness for getting going on this again I installed 1.8 and started to look at roles/permissions.

As I read through the documentation I saw comments about legacy roles. Looking at the site context I see "legacy role type" and "LEGACY ROLE:". One of these "legacy roles" is the "authenticated user" which I understood was new in 1.8.

Serching the documentation and forums didn't help me to understand this. I am trying to understand what has replaced them if they are legacy, if I need to worry about them, or what.

I am about to post a second question - it may be the same query in a different guise.

Can anyone explain to me if I should care about legacy roles and what has replaced them... permissions seem to be assigned to roles... that are described as legacy. I am therefore confused!

Thanks,

     Mark

Average of ratings: -
In reply to Mark Cornwell

Re: Legacy roles vs ???

by John Isner -
Please provide a hyperlink to the documentation where you read this so others can see what you're referring to. I would be surprised to see Authenticated user referred to as a "legacy" role. But life is full of surprises. I just checked my 1.8.2+ site and noticed that Authenticated user is one of the roles listed in the Legacy role dropdown. The primary function of Legacy role, as I understand it, is for backward-compatibility with modules that haven't been fully upgraded to the new roles system. Why Authenticated user, which was introduced in 1.8, should appear in that list is beyond me.

For further reading...
Average of ratings: -
In reply to John Isner

Re: Legacy roles vs ???

by Mark Cornwell -

John, authenticated user is not spoken of as legacy in the docs. It is where you saw it in the dropdown. I didn't spot it in 1.7 as my site was playing around with what Moodle could do rather than who could do what. I never looked at permissions.

On the documentation I am looking at:

Legacy to me suggests, for example in HTML, something that is deprecated. It will go away and I shouldn't use it if I am starting from scratch. But maybe (as in the student role link above) I have to individually allow things? ('Though I am not sure how I am meant to do that if they are already set in the permissions that I see when I edit a role - what more would I need to do?)

The result of what I read is confusion.

It would appear that there are a bunch of roles. From the docs there is a hierachical application of them with the closest "local" value that exists having priority. But then I read, as you did, when you go in to edit or view a role that it is a legacy thing... so maybe I should not use it.

For example:

Legacy role type: LEGACY ROLE: Authenticated user

OR, is this much more simple than all of that?

Is what this is saying more like this:

There were a  bunch of legacy roles. We now have redesigned roles. You can use a role that looks very much like a previously named one or you can design your own. Now, if you go in and edit a role you will see in legacy role type which of the old roles it is closest to. If you want to create your own role you are free to change to another legacy role.

For example, say you were building a "super student" role. Maybe that "super student" is closer to the old "non editing teacher" role than the "student" role. You could build all your permissions based on a duplicate of "student" but switch the legacy role type to "non editing teacher".

If you are new to Moodle you might just stick to the roles that are given. When you need to look at generating new roles think which of the existing roles it is closest to and create a duplicate of it. Leave the legacy role the same as the role that you modelled it on. If it is really a very different role than anything that went before choose a legacy role of "none" but be aware that without a legacy role being set your new role may have problems with some of the modules which have not yet been re-written to remove the need for these legacy role types.

I can't think why one would want/need to change a role's legacy role setting from what one had based a new role on in the first place. It would be simpler to build the role based on the legacy type that was closest... but at least it would make sense why there is a drop-down for legacy role type in the editing of a particular role.

Am I even close to being warm in my understanding of this?

Thanks,

 Mark

Average of ratings: -
In reply to Mark Cornwell

Re: Legacy roles vs ???

by John Isner -
Hi Mark,
I hope someone else responds to your question besides me.

In the old code, there were thousands of calls to functions like isTeacher(userId), isStudent(userId), isGuest(userId), etc. to make sure a given user was allowed to do something. In the transition to the new roles system, most of these calls were replaced by tests of individual capabilities, e.g., hasCapability(userId,'mod/assignment:grade') for a user trying to grade an assignment. As I said, MOST of the isX() calls were replaced, but some were not -- particularly in third party code. So as not to break the old code, the legacy capabilities were introduced and the isX() functions were reimplemented to test for these capabilities. For example, isTeacher() tests for the legacy capability moodle/legacy:teacher, isStudent() tests for the legacy capability moodle/legacy:student, and so-on. This is why, for example, when you view the role Teacher (site Administration -> Users -> Permissions -> Defined roles -> Teacher) you see the legacy role in the drop down. It means that the new Teacher role by default CONTAINS the capability moodle/legacy:teacher, thereby enabling old code to function properly.

Given my understanding, I have the following two questions:
  • Why are we permitted to CHANGE the legacy capability in a given role, since doing so will certainly wreak havoc with old code?
  • Why is Authenticated user in the dropdown?

Average of ratings: -
In reply to John Isner

Re: Legacy roles vs ???

by Mark Cornwell -

John, thanks for the really good info. As I had no knowledge of the "pre-capabilities" stuff and as I am an ex-programmer it makes much more sense now.

Given the understanding that you have shared I think I can partially answer the first of your questions (though certainly not the second).

You have certainly answered most of my headache.

Ok, take the example that I gave - a "super student" that you are creating. Say you duplicate "student" to create the new role. You set capabilities as you see them needing to work, but it doesn't fix things the way you wanted. Maybe, where you wanted a "teacher like" power you still get a "student like" power. It could well be that the awkward module is still Old School and is checking isStudent() and is finding that it is indeed a student. By changing the new role to be moodle/legacy:teacher the awkward module checks isStudent() and gets a "nope" back. It checks isTeacher() and gets "yes indeed". So it now treats that user as a teacher and you get what you wanted (maybe!!).

(of course, another Old School module could need to find isStudent() as true... but that's another problem :D )

That would certainly be one reason to have a legacy role changeable.

What happens if you set the legacy role to legacy:none or legacy:authenticated user.... well it probably breaks some modules ;)

As I said, you've told me what I needed to know. Where there was once "one" thing to test and one could have done something like a select statement where you test which role they fell into... now there are hundreds of things to test. More granular control. Maybe good, maybe bad, but certainly I can get my head around the mechanism.

For now I can leave students as legacy:student and so on. I only need to worry about them when I create custom roles, at which point I consider "what is this closest to?"

Thanks so much for taking the time to teach me the history.

   Mark

Average of ratings: -
In reply to Mark Cornwell

Re: Legacy roles vs ???

by John Isner -
Hi Mark,
It is certainly not straightforward. Take a look at MDL-9013 "Improve explanation of legacy roles."
Average of ratings: -