cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

In Permissions, Separate "Manage (add/edit/delete) course files" into 3 permissions

In Permissions, Separate "Manage (add/edit/delete) course files" into 3 permissions

Please change each the "Manage (add / edit / delete) course files" from a single setting to three separate settings.

 

Current:

Manage (add / edit / delete) course files

 

Should become:

  • Add course files
  • Edit course files
  • Delete course files

One reason for this request:

This would allow you to set TAs (or other roles) to having only the permissions needed for that role instead of none of them or all of them. For example, the ability to add and edit course files but not delete them.

This idea has been developed and deployed to Canvas

For more information, please read through the Canvas Release Notes (2021-03-20)

21 Comments
elisabeth_green
Community Participant

I promise I will not add an anecdote about TAs accidentally deleting course files to every one of these requests...  ;}

BROEKERC
Community Participant

Rationale: this functionality is needed as faculty have requested that their TAs be able to add or edit files but they don't want TAs to delete files. This is also needed in courses where there are multiple faculty. Having this functionality would eliminate the accidental deletions that happen now.

cdoherty
Community Participant

Rationale for Stanford: It's important to allow TAs to create content, but to restrict the delete permission to prevent accidental deletion of content.

millerjm
Community Contributor

We have some clinical faculty who may need to be able to add a file, but not edit or delete existing content. 

We have instructional support staff who may need to be able to add or edit (move/rename) a file but not delete. 

Taking away the delete button from anyone who doesn't need it just makes sense, especially since it would affect the students in a course.  We have a lot of accidental deletions that happen due to "goblins" in team taught courses. 

csalazar
Instructure
Instructure

It is clear that the accidental deletion of files is the biggest concern here. As I research a possible solution, is it safe to say that leaving Add and Edit permissions together would not be a concern?

elisabeth_green
Community Participant

That is incorrect, Cosme. We have had multiple cases where there was someone assigned to upload files (a course designer or TA) who made edits without the instructor's knowledge/permission. We definitely need to have these permissions separated.

cms_hickss
Community Contributor

We also have Sub-Account Admins who are supposed to be able to "edit" but not add or delete.

millerjm
Community Contributor

We also need to be able to separate the add/edit/delete.  We have cases where we need a student worker to be able to upload files but not edit/delete anything that is already there.  We also have team taught courses where they might need to be able to edit what is already there but not add or delete, as well as various sub-account admins. 

ginan
Community Contributor

As others have said, we have use cases for each combination of the 3 permissions.

For example:

  • A TA being able to add content but not edit or delete any existing content.
  • A Designer being able to add or edit content but not delete any existing content.
kristy_bergeron
Community Member

We would like to see these separated out as well. Our instructors are accustomed to D2L where they are able to add content but a TA cannot edit or delete it. Alternatively, would like to be able to allow designers to add AND edit content.

allison
Instructure
Instructure

This idea will be considered, along with several others, when we engage in a deep dive and audit of our permissions in Canvas this coming summer. If you are interested in participating in this discussion, please shoot me an email: allison@instructure.com​ As we consider all of the possible permission granularity requests (see Canvas Permissions and Granularity Feature Ideas), we will be considering a number of different factors, including the COST and the BENEFIT of making a change:

THE COST

What extra work will be required in the Canvas app if we break out this permission?

What is the level of engineering effort required to implement this permission split?

What will it mean for us to support this new permission indefinitely as we add new features?

THE BENEFIT

What use cases would this granular permission support?

How many of our existing customer require support for each of those use cases?

These are not the only considerations, but I mention this line of reasoning because between now and the summertime when we start to dig deep into this topic, voters on this thread have a big role to play in persuading us of the potential benefits to admins and users. Your votes and comments will help us to measure the percentage of our customer base that will actually use the permission split, if implemented.

Bottom line: Keep those votes, comments and use cases coming! They will be very valuable when it comes time to decide which requests to prioritize.

millerjm
Community Contributor

We need some support for our case that the permissions available in Canvas are not sufficient for our needs.  Above is the update that Allison Weiss posted to many of our feature ideas.  She is asking for use cases for granularity and we really need to justify each and every one.  I made a document to track discussions and feature ideas related to permissions: 

Canvas Permissions and Granularity Feature Ideas

This is the sort of information that would assist in getting these changes made during this permissions audit.  This information would need to be added as comments to the individual feature ideas, and if it needs to be pasted to more than one, then please do that.  I know it's tiresome to post the same thing again and again, even though someone else has already done it, but they need to see that it's not just 5 people with these issues!  We haven't gotten much traction because we haven't had enough use cases posted but my document above seems to have gotten some attention.

  • What has the current user permissions "bundling" and lack of granularity cost you in terms of support and functionality?
  • What permissions have you HAD to grant to someone simply to allow them to be able to do their job, that you would have rather NOT given?
  • What permissions have you had to DENY giving someone because it gave them access to something that you could not due to security, concern about causing trouble, etc.?
  • What other qualms do you have about things?
  • What things have cost you more in staff hours because of denying access to someone, means that your department had to research, do work, etc, on behalf of a user that would have been able to do their work if the permissions were granular?

Thank you!

Joni

I'm also tagging  @kona ​ and cms_hickss​  since they have been so involved in getting attention to these feature ideas. 

Renee_Carney
Community Team
Community Team

Greetings, Partners on Permissions

Thank you for the time, energy, experience, and knowledge you have put into these threads.  The granulated permissions threads have been open and gathering information for almost a year now.  This extra time has allowed our team to collect important feedback and perspectives.  Each of the permissions threads contain valuable stories that will help inform development if/when a project is allocated for.  Having worked with Allison on these, and now working with Matt G., I know that the product team is sincerely interested in improving permissions, however the magnitude and impact of such a project does not make it one that is easy to squeeze in.  We will be archiving these permissions threads for now.  Archiving these threads does not mean they are forgotten; they are set aside, while they are inactive projects on our roadmap.  The ideas are monitored, so you can continue to add your examples and use cases to the dialogue.  Please follow this thread to receive updates when they are available.

Again, thank you for the rich conversation!

Boekenoogen
Community Contributor

Archiving is Instructure lingo for it is not going to happen.

cms_hickss
Community Contributor

There's still hope. Many of the permission Ideas have received a second chance as they have have been moved from "Archive" to "3.25 Product Radar." There is a good chance that this one will be moved as well and that  @Renee_Carney ​ has just not yet gotten to it.

Renee_Carney
Community Team
Community Team
  Idea is currently in Product Radar Learn more about this stage...
Renee_Carney
Community Team
Community Team

The Radar idea stage has been removed from the Feature Idea Process.  You can read more about why in the blog post Adaptation: Feature Idea Process Changes.

 

This change will only impact the stage sort of this idea and will not change how it is voted on or how it is considered during prioritization activities.  This change will streamline the list of ideas 'open for voting', making it easier for you to see the true top voted ideas in one sort, here.

cms_hickss
Community Contributor

For this idea, please remember to follow:

The first step to getting Granular Permissions was completed with the Permissions: New Interface.

Stefanie
Community Team
Community Team
Status changed to: On Beta
 
Stefanie
Community Team
Community Team
Comments from Instructure

 

The Course Files - add / edit / delete permission has been grouped into three separate permissions. This change provides granularity among the three options to manage course files. This update does not affect Canvas APIs.

For more information, please read through the Canvas Release Notes (2021-03-20).

About Idea Conversations
In the Instructure Community Ideas space, you can share, converse, and rate idea conversations related to software improvements to Instructure products.