Let's Talk More Granular User/Role Permissions

cms_hickss · ‎06-22-2017

Permissions are always an interesting thing to discuss. Everyone has a slightly different take on what "permissions" mean and what to associate with this project. I'm going to use this space to hopefully house the thoughts from the breakout session from Project Khaki. Plus, the thoughts that went into making the Idea requests that have been compiled in the Canvas Permissions and Granularity Feature Ideas document.

New! July 23, 2019
An update was posted in the https://community.canvaslms.com/ideas/1527-more-granular-permissions-for-admins?messageTarget=all&st... Idea. That stated: "We're [Canvas] assessing each permission 1 at a time. Some are included in our product plan for Q3 2019 and will influence development within Canvas."
[Edit 12:90pm ET] Renee Carney let me know that the update on the permissions page was incorrect and it is NOT on the plan for Q3 2019.

July 9, 2018

The new User Interface for the Permissions Page will hit production with the July 14th, 2018 update.
Posted by Erin Hallmark: Permissions Name Updates (2018-07-14 Canvas Release) - the Permissions page includes updates to permissions names, which have also been grouped according to function. No permissions functionality has been affected.

Who does making the current user role permissions more granular impact?

Everyone. Well, the student role itself will probably not be impacted, but the roles of the user's who support students just might be. Permission on roles impact users from TAs to Teachers to Admins, even to a Dean/Chair who just needs to see and not do an action in a course

How is a Role different from a Permission?

Role - A role is basically what a user is defined or identified as in the Canvas. And, a user can have multiple roles based on what s/he needs to do. Roles include: TA, Teacher, Designer, Student, Observer, Admin, and any custom roles your school may have created, like Principal, Auditor, Chair, Tutor, etc.
- And, there are TWO categories of roles
  - Course: Teacher, TA, Designer, Student, Observer
  - Account: Think administrative roles for this one, like Principal, Dean, or system admin.
Permission - Permissions are the actions that a role can and cannot do. And, keep in mind, Account Roles can have Course Role permissions.
Example of a Permission in action. Let's pick the action of creating a quiz.
- The students role does not have the permission to create a quiz.
- The TA role, based on the settings of your school, may have been granted the (current) permission of Manage (add / edit / delete) assignments and quizzes.

What is meant by granular?

It means separating out any permissions that is multi-functional to individual (and independent, more on that later) components. In other words, "add, edit, delete" should not be a single permission but three.

Is three enough?
Probably not. There also needs to be a "view" or "read" only option.
- Now you might be asking, "but why might I need that?"
  Ever have a Dean/Chair/Principal need to see how a teacher is teaching a course? But does that Dean/Chair/Principal need to modify content or grades? If not, then a "read only" option would serve them best.
- Does "read" need to do anything else?
  Yes, it would be best if it could ignore conditional release criteria.
Now that Independent thing you mentioned above, what does that mean?
- Ah, independent means a permission shouldn't be reliant on another permission to do what what the permission states that it will do.
  - Example: To "add, remove" a student from a course a Role should not need to have a second permission enabled to do this. The actions to add or remove a student should include (behind the scenes) everything required to allow that action/permission to be done and not require you to know what secondary permission also needs to be selected for that action to actually work.
  - Are you asking yourself, "huh?" If so, what happens is that sometimes there is a second permission (the one you might have had to look up in either the Canvas Account Role Permissions Guide or the Canvas Course Role Permissions Guide) that might be required just to get the one you were trying to add to work... and, that extra permission now may allow for even more (unexpected) actions by the Role which you had not intended to grant that Role.

Still with me? And yes, it's okay to be confused. This can definitely get confusing. :smileycool:

Now why is all this important?

Changing the current set of permissions would allow for, you guessed it, more granular control over permissions. These granular permissions would allow for more customizable out of the box (defaults like teacher, TA, etc) and school created roles (like principal or auditor). What all this means is that Admins would be able to allocate the correct permissions and/or create new Roles with the appropriate permissions that their users need to successfully use Canvas for teaching, learning, and in the support of their students and teachers at their institution (which, and I'm betting you may have already figured this part out... might vary from what you might need to do a similar action at your institution).

Documentation

Before we get to far, permissions should be thoroughly documented in the guides.

Language of a Permission

A permission should be worded, as simply as possible, for the actions in which it does. And this action should be documented in the, well, the documentation.

An example might be useful here. [Note this is only an example and is not an actual setting at this time.] Let's say that new "Edit" permission on an Quizzes allows you to change everything but the "Allow Multiple Attempts" option if some students have already taken started the quiz. Then this needs to be stated on the documentation for the permission.

Settings on a Permission

Currently the settings on permissions are:

Enable
Enable and Lock
Disable
Disable and Lock
Use Default

But what does that mean. Enable means to turn on or allow that permission for a specific Role. Disable means to turn it off or disable it for a specific role. The Lock option means that it cannot be changed at a lower level (such as a college , grade, or department level if you are using Sub-Accounts with your version of Canvas). Use Default means that you want to use what Canvas has set for the default on that permission.

Wording on Permissions I

The (add / edit / delete) wording, needs to be updated to encompass the actions those options will allow. This means that 6 options are needed along with the ability to lock the permission down.

All - the ability to create, edit, and delete an item
Create - to add or create a new item (ex: create a new quiz)
Edit - to edit or modify an existing item, but not have the ability to delete (ex: the ability to change an end date on a quiz)
Delete - the ability to delete / remove an item (ex: delete a quiz that is no longer needed)
Read - the ability to only read or view items (ex: see a quiz without taking the quiz or editing it)
None - does not need this permission

Wording on Permissions II

But what if you need to set two of the options? Like "Create" and "Edit".

Still with me? This is when some might say this issue becomes a little more complicated.

Other Items that Need to be Considered with the Changes to Permissions

The layout of the permissions page
The order of the individual permission (alphabetical or by content type)
- Content Type. The grouping of the permissions by content type (ex: communication tools) and then individual tool/component (ex: chat, conversations, collaborations)
  - Something like this:
    
    Red X = Disabled; Green Checkmark = Enabled; Glasses = Read Only [Note the glasses option does not currently exist]

A Love to Have with this Change, Part 1

Separate Page/Screen for Modifying the Permissions on a Role

It would be easier to manipulate the permissions of a Role if that Role opened in a "new window/page" when making edits to that Role's permissions. The current Permissions page makes it very difficult to mange a Role. If you're not sure what the Permissions Page currently looks like, scroll back to the top of this blog post and check out the image used in the header/banner. Are you back? Yep, that's current permissions page.

Here's one of main problem with that page. It is easy to lose the role and permission you are trying to set as neither the Role Column Titles or the Permission Row Titles move/scroll with you. Currently, many admins use the make that browser window the size of the monitor, shrink the actual text so the entire page fits, and then put post-it notes at the top and bottom of the column they are trying to modify.

I wish I was joking here, but have a picture.

The current permissions page could probably work as a quick overview of your institution's roles and permissions but it is not the screen to actually use to build or modify a permission on.

Maybe a secondary page for each Role that looks something more like this:

[Image does not address the issue of needing "create and edit", "create and delete", or "edit and delete"]

This new page would allow you to see/do:

the Role's Name
the Role's SISID
only that Role's permissions
lock a setting with click of a box
have an actual "Save" and "Cancel" buttons for the Role/Permission changes [Note that the current Permissions page has no Save button and all actions are saved at time of change even if you have accidentally clicked on the wrong column/Role and permission and don't realize that until too late -- see image of current page layout that is up ^ there.]

How to address the need for 2 options on a permission.

Maybe it's as simple as adding those three into the dropdown, like this:

A Love to Have with this Change, Part 2

Tracking/Audit/Rolling Back

Audit/tracking on permissions for when changes are made. The first iteration of this could simply be a last updated timestamp on the permissions page. At least with this simple addition you would know the last time a change was made to the permission.

Other items that would be nice for tracking purposes:
- Who made the changes?

If each Role had its own page for editing, the audit log would be for that single Role with the possibility of rolling it back to the previous options, clearing the permissions altogether, or even resetting the Role (for one of the out of the box Roles).
- The Role Specific Page could look something like this:
  
  [Image does not address the issue of needing "create and edit", "create and delete", or "edit and delete"]

^Updated Other Important Pages to Look At

Not Included in this Request

This change to Canvas is not meant to include Teacher controlled permissions for individual courses (at the course/section level). That's a whole other idea that would need to come after this one. But quickly, what is meant by Teacher controlled? The ability for a teacher to say, turn off or on the "Conversations Tool" for one of his/her courses [if that was a setting (in canvas) that was enabled at the institution or sub-account level].

Other Important Things to Remember with Roles

When you copy/duplicate an out of the box role it carries with it the category that it was copied from. In other words, if you duplicate the Teacher Role and name it "Principal" (both name and SISID) and then assign that role to a user, other users (including students) will see that user listed under "Teachers" in the People Tool and in the Conversations Tool.

This is bad. Why? Because a student might not know that Person X isn't really a teacher assigned to that course/section and that this person should not be contacted if you have questions or need help with course content.

Newly created roles should not automatically be assigned to the same role category as the role it was duplicated from.

Granular Permissions is now part of the Canvas Studio. Read more about it.

New! July 9, 2018

The new User Interface for the Permissions Page will hit production with the July 14th, 2018 update.
Posted by Erin Hallmark: Permissions Name Updates (2018-07-14 Canvas Release) - the Permissions page includes updates to permissions names, which have also been grouped according to function. No permissions functionality has been affected.