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.

[jazemlya]

I just ran into this issue with creating a custom role for our account auditing team.  They only needed specific functions to do their job and i had to follow the same route as above to see what happened when turning certain permissions off and on until i found the right mix of needed access but nothing outside the scope of what they need to do.

[zachw]

The granularity is important. Also important: some sort of descriptive text that explains exactly what the permission covers.

[mlattke]

I run into this all the time.  Even a list of all the things that are included under each current permission would be a helpful thing.  But there are some things that are grouped together that sort of mystify me.  Agree 100% that this would be a useful addition/change.

[kona]

Yes. This. - "But there are some things that are grouped together that sort of mystify me."

[carol_walsh]

We are wondering how we could allow teaching staff to moderate a quiz without giving them the permission to ‘Manage (add / edit / delete) assignments and quizzes’.

I expect a lot of Canvas users both develop and deliver courses. For TAFE NSW however, these are two different roles (Develop and Deliver). For us, giving a student more time to submit is clearly a deliverer role, whereas being able to add, edit or delete any quiz or assignment to the course is a developer role. And yet Canvas conflates the permissions. (Interestingly, there is a separate permission for moderating a forum – Would love to know how this came about).

I see this not so much as a feature request but more sorting out the logic of the permissions. I expect the issue is not relevant to most Canvas users who don’t mind conflating develop and deliver roles because they do both. For our business the distinction is fundamental.

[miltonv]

Currently there is an account level permission to view course content, but not a course level permission.  We need certain users, such as course evaluators, to have the ability to view all course content in a course without viewing student information or modifying the course in any way.

[tdelillo]

Recently, our teachers lost the ability to add Observers, because that permission was once bundled with the ability to add teachers and TA's, but then it got bundled instead with the ability to add students (which we do disable for our instructors, to keep the students enrollments matching the SIS). Perfect example of how bundled permissions get messy (and this was also a change that was not described adequately in the release notes).

[cms_hickss]

I'd like to see all the permissions with the "add, edit, delete" functionalities to be split into three so that each option is its own permission.

[kristin_bayless]

I agree with the add, edit, delete, plus "display only" is also very important.  This differentiation is esp. important in the area of assignment markup and grading in Speedgrader and the gradebook.  I'd actually like the ability to add a comment to an assignment in Speedgrader unbundled from the grading process.  We have outside experts who assist with certain classes who can coach students on their submissions, but we wouldn't want them giving grades.  On users and accounts, the ability to view users should be removed from the ability to add users. 

[PSU_Tony]

The permissions definitely need to be more granular. I don't feel the documentation has a firm grasp of them.

[ctmath2]

I agree on the granularity.  The permission options seem very limited.  Also, some of them--depending on the role--you can't modify.  I understand why this is the case offhand since you probably don't want to give course management options to a student, but still, I think what permissions are allowed for each role should be fully customizable. 

[asatkins]

Yes please! We have 10 different admin level roles and so many permissions to VIEW are tied to the permission to ADD/EDIT/DELETE! Some documentation has been helpful, but more granular permissions would be so amazing!

[asatkins]

I think, also, a cross listing of permissions that are assumed as the same. For example, announcements are linked to the discussions permission, but only one of them (view discussions). I think there's an assumption that people just know that those two are both considered "discussions", but I had no idea until we turned them off on our instance.

Also some of the terminology that either seems interchangeable and means something entirely different (question groups vs quiz banks, for example) or is the same language but refers to more than one thing (all quizzes/discussions are "assignments" but there is also a separate content type called "assignments"). I know this is long term, but it would be really helpful in terms of knowing we're talking about the same things when we speak.

Maybe until this happens we can start a conversation somewhere on what we've all found by accident? It could help us get by for now?

[scottdennis]

Hey Tony,

Just in case anyone following this thread hasn't seen it, we do have these descriptions: https://s3.amazonaws.com/tr-learncanvas/docs/Canvas_Permissions_Account.pdf

[PSU_Tony]

Thanks Scott, that definitely helps!

[harker]

This is a big problem for admins. AMEN!

One thing that would even further the help is to have a specific definition and what the permission does effect when used. It really stinks to find that when granting permission to do one thing to make the admin job easier, it also grants the end user the access to Pandora's box.

It is not good when you have to take away someone's access because they "did not know" (actually listen) that was a hands off feature.

[tdelillo]

Also, the course level permissions: https://s3.amazonaws.com/tr-learncanvas/docs/Canvas_Permissions_Course.pdf

[tdelillo]

Apparently the ability to add observers was recently returned to the "Add teacher/TA/designer" permission. Which makes me happy, but we really need better communication about changes to permissions.

[mlattke]

Wow!  How did I not know these existed?  I have been looking for this information for ages!  Thanks,  @scottdennis ​!!!!!!

[JanineJones]

Granular permissions would be amazing!

I would also love to see the create/edit/delete broken up as mentioned by cms_hickss. The option to specify settings for the manually and SIS generated courses would be a tremendous help as well. We have a lot of manually created courses that teachers should be able to control, however that also means a lot of the same permissions are given to users for courses generated by our SIS.

As a tech heavy district, it would be a relief to give the teachers the freedom to build and explore with Canvas, without having to worry about what permissions I may have given users or inadvertently taken away in one swift click.