Let's Talk More Granular User/Role Permissions

cms_hickss
Community Contributor
21
3834

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

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:  
        228018_pastedImage_1.jpg
        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.

239450_pastedImage_21.jpg

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:

239368_pastedImage_10.jpg
[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:

239460_pastedImage_18.jpg

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:
      239368_pastedImage_10.jpg
      [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.
21 Comments
tdelillo
Community Champion

Thanks for writing this, cms_hickss! Tagging  @Sylvia_Ami ‌ and  @garth . I think we were the only 4 non-Instructure folks on this "team", am I right? Khaki was becoming a blur at that point... Smiley Wink

rconroy
Instructure Alumni
Instructure Alumni

I'm excited to see how you all fleshed this out. This was my other iniative that I would have joined had I not gone the way of Advanced Reporting. Permissions make my head spin. 

tdelillo
Community Champion

It definitely does make the head spin. Every angle we looked at took us in weird new directions. Which is why we had such a beautiful lack-of-presentation when it came time to report out Smiley Wink

rconroy
Instructure Alumni
Instructure Alumni

That is EXACTLY what happened with the Advanced Reporting. We would start to go in a lot of new directions because it was hard to define and explain. I think your group and our group were the only ones that worked off the GoogleDoc hahaha 

kmeeusen
Community Champion

Nice Start, Susan!

I hope you will share more as you get time. I wasn't in your group, although I did of course see your final wrap-up.

Kelley

garth
Community Champion

My take away from our group is that this issue is not trivial.

Privs touch everything, it runs deep.

There are a lot of perspectives on this topic, and opinions on how it should be implemented.

Hopefully we were able to provide some of that perspective, and some useful information, back to the Canvas team.

They have a serious challenge ahead of them.

I thought all the groups presented very well at the end of the day.

Kudos to cms_hickss‌ and  @tdelillo ‌ for representing us to the entire room : )

I feel lucky to have had an opportunity to meet you all.

garth
Community Champion

 @tdelillo ‌ I agree 100%  We definitely went down a few rabbit holes...more like a full rabbit warren.

It was a very interesting exercise, and demonstrates the complexity of the "idea".

jazemlya
Community Contributor

Thanks for putting this together Susan!  I think my biggest concern about the work associated with this is what we don't know.  Its obvious that some permissions can be easily separated such as Create/Edit/Delete.  My concern lies withing permissions hidden withing permissions that are not apparent.  For example we have instructors that want us to turn off the ability for students to “Send messages to the entire class”, but we cannot because one of the unfortunate side-effects is that this also prevents students from sending messages to members of the groups to which they belong unless they select each group member individually.  Our Accessibility team has found this to be a huge issue and has requested we not turn disable “Send messages to the entire class”.  If i could disable the ability to send to the entire class in Conversations but still allow students to communicate with Groups they are in would solve the issue for us.

Using the example above, i fear what other permissions need to be separated out that i am not aware of that are not as clear as create/edit/delete.  If anyone has any other examples of this it would be great to share in this thread so Canvas is aware of other needs we may have.  Thanks!

cms_hickss
Community Contributor

 @jazemlya , are you wanting that to be a "course" permission so you can set it for an individual course(s)? Or, are you wanting this to be a system-wide setting?

Also, the "hidden" permissions are why we have asked for individual and independent permission. But, that request would not handle a setting/permission for individual courses which is like part 3 in the master plan of canvas settings. Smiley Happy

jazemlya
Community Contributor

What i described above is a course role permission for the entire system, hence part of the “Send messages to the entire class”, so i would like to have them split out globally so that we can maintain the ability to email a discussion group, but disable the ability to email an entire course for any "student" role in the entire system.  Does that help?

tdelillo
Community Champion

Thanks for updating this, it is so full of wonderful ideas!

The feeling I've had ever since Khaki is that the complexity of the desired granularity is breathtaking. And I'm trying to find a way to simplify. I keep envisioning a grid, like this [forgive my lack of artistic skills]:

241637_PermitGrid.jpg

This isn't a unique idea, we have systems with similar permissions grids.

Now, having them broken out like this removes the need for an "ALL" option. And I also removed the "DELETE" option. I know there is a case to be made for Edit/Delete to be separate, but to me, you have the same set of risks with both. Someone with Edit permissions can do just as much damage. And actually, the undelete function can sometimes put things right easier than trying to figure out what changes were made by an unwitting editor, especially with tools that don't have a built in history, like Assignments.

Thoughts?

cms_hickss
Community Contributor

I think you're still going to need delete as one of the options on a file is "delete" there is no "edit". There are many tools (Quizzes and Announcements) where there is a "delete" option in the action menu. What we would like to see is that option not there.

Especially on a Quiz where Delete appears in the "action menu" and Edit is a separate button where within edit your only options are to Save and Cancel.

cms_hickss
Community Contributor

I'm going to mention it here just so that there's a note about it. The new tool Blueprint came with one set of permissions:

Blueprint Courses (create / edit / associate / delete)

Like the rest, this one too should be granular/separated into at least 4 separate permissions.

cms_hickss
Community Contributor

I have updated this page to include a link to Canvas Permission Updates which you can follow to be alerted to when Canvas updates or adds a permission.

I've also added a warning about duplicating out of the box roles.

jayde_colquhoun
Instructure
Instructure

We are definitely screaming out for more granular permissions.. and for permissions to be reviewed in general. We have a large presence in Canvas, now with over 600k enrolments in Canvas courses, and so many different access levels needing to be housed for different roles. I especially identify with  @jazemlya ‌ 's comment regarding permissions that govern other permissions.. Thank you for sharing. 

cms_hickss
Community Contributor

If you haven't seen it yet, you should read  @mbenson_sales ‌'s Khaki 2018 Update  where he mentions that Admin Role Granular Permissions part 1 is on the roadmap for InstructureCon 2018 and part 2 is set to be delivered after. [Part 2 being breaking out the permissions and part 1 covering  new interface that will be able to handle that change.]

jayde_colquhoun
Instructure
Instructure

I’m yet to see that but will head over now and take a look, thanks! 

cms_hickss
Community Contributor

New Items

  • 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.
  • The new User Interface for the Permissions Page will hit production with the July 14th, 2018 update.
cms_hickss
Community Contributor

On Tuesday, July 23rd Canvas made a note on the https://community.canvaslms.com/ideas/1527-more-granular-permissions-for-admins?messageTarget=all&st... Idea.

We're assessing each permission 1 at a time.  Some are included in our product plan for Q3 2019 and will influence development within Canvas.

It comes with the additional caveat of:

Adding this idea to our product plan means we will be working on it, but it does not guarantee that it will be developed exactly as defined by the idea, or that it will be added to the production environment.
kmeeusen
Community Champion

Woo hoo!

cms_hickss
Community Contributor

[Edit 12:90pm ET] Renee Carney let me know that the update on the https://community.canvaslms.com/ideas/1527-more-granular-permissions-for-admins page was incorrect and permissions are NOT on the plan for Q3 2019.  Smiley Sad