More granular permissions for admins

[kona]

Right now setting Permissions for different course and account roles is very difficult because many of the permissions are tied together so you can't have one permission without also having the other checked. Yet, there is no list of what each permission actually impacts and which permissions are related to each other.

When we are developing a new role we almost always go through the lengthy process of:

• adding a permission to a role
• logging in as someone with that role and checking to see if that person can do what they need to do but not things they shouldn't do
• if the setting isn't correct, then going back to permissions and try checking or unchecking something different to see if we get the desired result
• wash and repeat

If permissions were more granulated and separated out it would be much easier to (1) understand what the permission actually controls and (2) provide the right level access to specific users.

Comments from Instructure

The New User Interface is included in the Canvas Production Release Notes (2018-07-14) .  Go check it out!

  Comments from Instructure

The LTI - add / edit / delete permission has been grouped into three separate permissions, as detailed in the  Canvas Release Notes (2022-01-15).

🔎 This idea has been archived. While this idea isn't open for comments, it is an important part of Instructure’s idea conversations and development process. Contributions like this are valuable as Instructure prioritizes work on new or existing features.

[agilbert]

We would really appreciate more granular Canvas permissions. Trying to translate our Blackboard privileges into Canvas permissions has been quite an undertaking. Bb is very granular, so it's not a 1:1 process.

[cms_hickss]

Yes, it's the "add, edit, delete" issue as one setting. We had/have that same problem and we came from BbVista.

[emiller]

Would love the ability to enable admins at the sub-account level to become other users. It is too big a security issue to allow this now since it can only be done at the "root" level rather than restricted to sub-accounts.

[mlewis23]

The granularity of permissions is a very important issue.  We currently have to break one of the golden rules of admin and dole out more permissions than are necessary.

[accook]

I agree!

[millerjm]

OK, so I found another repercussion in giving this permission to faculty in order for them to view prior enrollments - is they can conclude enrollments, which we only want done by SIS imports or by an admin. 

[millerjm]

I agree, you shouldn't have to give access to something because it's bundled with something else - and telling someone "don't touch this button" isn't sufficient because they forget and someone eventually does, usually by mistake. 

[csalazar]

The interactions between permissions in Canvas can be confusing. Our documentation team has worked hard to document many of these interactions in the Related Information column of these documents:

Account Role Permissions

Course Role Permissions

It is a challenge to balance giving admins the power to control user access at a granular level while also keeping the list of permissions to a number that is not overwhelming. We do not have capacity to do a complete overhaul of permissions in the next six months. If there are specific permissions that are lacking, please submit and vote on those issues as there may be specific changes that we can prioritize more quickly.

[mzucal]

This is a big disappointment that it will not be addressed in the next six months. The limits of the permissions in Canvas makes an admins job harder and we have to say no more than we want to in order to preserve security.

Does the archive status mean that if we want to have this looked at after six months we have to post it again in the feature requests?

[mzucal]

I also think you are underestimating the admins when Canvas want sto limit the permissions so they are not overwhelming. We can figure it out.

[cms_hickss]

I think any permission that is "ADD, EDIT, and DELETE" as one setting needs to be divided out.

So Deactivated user​ you are saying we need to open up/create another request specific here in the community for changing a permission setting from granting "ADD, EDIT, and DELETE" as one single permission to that of three separate permissions.

And, do we need to do that for each permission where that appears?

[kona]

Here's a good example of why permissions need separated out - What permission is de-cross-listing tied to? - it's clear how to allow a role to cross-list, but not at all clear which permission is aligned with the ability to un (de?) cross-list.

[cms_hickss]

I have submitted:

[cms_hickss]

​ has been approved and will open for voting on August 5th.

[cms_hickss]

I was asked to separate out and have now created 10 separate requests to cover each permission that has an add/edit/delete/remove set of options.

1. " style="color: #2989c5;
2. " style="color: #2989c5;
3. " style="color: #2989c5;
4. " style="color: #2989c5;
5. " style="color: #2989c5;
6. " style="color: #2989c5;
7. " style="color: #2989c5;
8. " style="color: #2989c5;
9. " style="color: #2989c5;
10. " style="color: #2989c5;

[canvas_admin]

Wow cms_hickss​, thanks for the effort in doing this!

[millerjm]

Thanks, Susan!  I had considered doing this but you beat me to it. 

[ctmath2]

It needs to be unbundled and made it's own permission.

[cms_hickss]

I can add observers into the " modifiedtitle="true" title="In Permissions, Separate "Add/remove other teachers, course designers ...​ request.

[tdelillo]

Might be a good idea, since it's part of that permission. I also realized that custom roles get lumped in there also, seemingly if they're based on the teacher or TA or Designer Role. It might be useful to add "Add a custom role"/"Remove a custom role" to that separation request as well. However, given the oddities discussed in the ​ request, it seems like the custom roles retain so many qualities of the role they're based on that it might be really hard to separate them out.