Viewing roles with API

[Greg Sabatine]

I have set the permissions in the LE to allow a certain role to "see roles" but they are not able to see any roles when I run the '/d2l/api/lp/(version)/roles/' call. Is this just a case where the Valence API permissions do not align with the LE permissions?

[Greg Sabatine]

I'm glad I posted here .. I'm getting so much help... haha

[Desire2Learn Staff: Viktor]

Greg -- when you say "you cannot see roles", do you mean that you get a 200 with an empty list, or that you get a non-200 response?

[Greg Sabatine]

Hi Viktor,

I get a 'Forbidden' response when I try the call.

[Desire2Learn Staff: Viktor]

Thanks, Greg -- I'll have a look at this when I have a minute -- it won't be right away, but I've already started looking so there shouldn't be too much of a delay. Can you follow up with the 'Security' group permissions that your user context actually does have, please?

[Greg Sabatine]

This user role has the ability to 'See Roles and Permissions' at the Organization level. That's the only option selected.

[Desire2Learn Staff: Viktor]

Ah. Yes. I know it's counter-intuitive, but I believe that your user context's role needs to have 'Manage Roles' at the Org level in order to use the GET roles API call. I have followed up with dev staff on why this is, and the counter-intuition here is down to language for description and not necessarily a flaw in intent.

The 'See Roles and Permissions' perm is intended to be the general permission that lets a user see the 'Roles and Permissions' tool at all in their tool selection fly-out in the Web UI. To be able to see the list of roles and permissions in the Web UI, the user will also have the ability to change them -- we don't really have a concept in the Web UI of having access to that list without the ability to manage the list (modify it).

Therefore, the call in the API that gives you access to the list is governed by the same permission that would let you see the list in the Web UI: not See Roles and Permissions, but Manage Roles and Permissions.

I will update the docs to be a bit more clear for this call, because clearly this is an area where the wording used could lead people to fall into exactly the same problem you've encountered here.

[Greg Sabatine]

Thanks, Viktor.

That's what I thought. I will submit this as a bug/feature request.

[Desire2Learn Staff: Viktor]

Actually, Greg, it would be best if you didn't because I believe that this would get discarded or not acted upon as "working as designed". Please see my revised answer to this query. Actually, I'll update the docs right now for clarity around this, which is likely the only action that would address this as a defect anyway, and we can save you and our support path some time if we just handle this right away here by updating the docs.

[Desire2Learn Staff: Viktor]

I have in fact just updated our docs to say "returns list of roles you have permission to manage" not "see". I hope that should be sufficient.

[Greg Sabatine]

It's sufficient for clearing up the confusion but not for my application. I still need the user role that can 'see roles' to be able to view all of the roles through the API call. I will submit it as PIE idea and hopefully it will get picked up eventually.

[Desire2Learn Staff: Viktor]

Well, I don't want to dissuade you from making that request, and the enhancement might get adopted; however, I will advise you that the current functionality is seen as working as designed, and so the request would get treated with the attendant priority for that -- as an enhancement that we might make to the product should we perceive a wide spread need amongst our clients, but likely not given the priority that we'd give to a defect to our platform.

As far as I know the call has never depended upon the 'See Roles and Permissions' permission, but on the 'Manage Permission', so this is down to a mis-match in expectations caused by terminology and wording used in the docs or arising out of the user experience -- a mis-match I fully sympathize with, mind you, but still, not strictly speaking a defect.

If you have reason to believe that the API call did once depend upon this permission, but now does not, then please let me know and make sure to express that in your incident report, because that kind of functional  change in the API that breaks backward compatibility would be a different matter entirely.

Thanks, Greg.

[Greg Sabatine]

Viktor ... my suggestion ... fix the terminology on the current call and create a new call that allows a user to see roles when "see roles" is enabled. It doesn't make sense to have a call to see roles and have 'manage roles' as a necessary permission. I've already submitted the PIE idea so hopefully that helps somehow.

[Desire2Learn Staff: Viktor]

Well, really it's down to terminology and not functionality. One way to address this would be to go into the language terms for roles and permissions and turn:

See Roles and Permissions --> Access to Roles and Permissions tool

Manage Roles and Permissions --> See and Manage Roles and Permissions

If we changed just the first of those, it would be a lot clearer. The wording for roles and permissions makes more sense in the context of only having a WebUI for the back-end services, and the translation of using them in the API context causes hiccups like this reasonably frequently.

--
V.