In Permissions, Separate "Add/remove other teachers, course designers, TAs, and Observers to the course" into 8 permissions

[cms_hickss]

Please change each the "Add/remove other teachers, course designers or TAs to the course" from a single setting to 6 settings.

Current:

Add/remove other teachers, course designers or TAs to the course

Should become:

• Add teachers to a course
• Remove teachers from a course
• Add course designers to a course
• Remove course designers from a course
• Add TAs to a course
• Remove TAs from a course
• Add Observers to a course
• Remove Observers from a course

This idea has been developed and deployed to Canvas

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

[glparker]

I don't have a specific use case, but I dread having to manage a combinatorial explosion of permissions using the existing Manage Permissions interface.   Is there another feature request out there for improving the experience of creating and managing User Permissions?

[cms_hickss]

There is this Idea Request:

" target="_blank

[glparker]

That would do it.   If you are voting for more permissions, you should also vote for a better permission management page.

Thanks

[hesspe]

My greatest concern is this: I want to prevent the avalanche effect where someone can add people in a role, who can add people, who can add people...

To be concrete: Suppose Teachers can add Teachers.  Joan adds Bill as a Teacher; Bill adds Shirley as a Teacher; Shirley adds Bob as a Teacher, Bob adds Mary, Tim, Jane, Max, Julie...

It might be much more difficult to implement, but I would find it acceptable, even desirable, if one master teacher for any course had the ability to add any number of co-Teachers, but none of the second tier Teachers had that same ability (while having all of the other Teacher permissions).

The other thing I think would really help those of us who try to be a  conscientious about FERPA compliance is to separate the ability to grade student submissions - a key TA function in many courses - from the ability to see and edit the Grade Book .

[allison]

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]

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]

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!

[chriscas]

While I do understand what a monumental task making permissions more granular is going to be for Instructure, I don't think is is something that should be continually put on hold or delayed infinitely.  The original request is already a year old now, and now hearing this can't even make it to the roadmap (which is a year out basically, right?), means we won't see any action on this for quite a long time.  With the growth of Canvas adoption around the world, it seems like Instructure should be able to hire additional developers and devote at least some time to issues like these.  I know there's some great new additions coming down the road this year, but hopefully some time can be devoted to fixing some underlying Canvas code issues like this, which may not be immediately noticeable to students or teachers.

[millerjm]

chriscas​:  Thank you for summing this up so nicely.  Permissions aren't cool and pretty and shiny to show to new clients.  However, they are very important to technical and instructional design staff who have to either complete work due to not being able to grant permission to something because it's bundled OR who have to fix things that got broken due to granting bundled permissions. 

Admins would be much happier campers with more granular permissions AND have more time to help faculty and students if these permissions improvements were made.

[Eric_Roussel]

Ability to remove observers that have 'observing nobody' in a single delete by teachers for year level classes. Currently we have a mixture of student movements depending on electives and we remove students from a class but the observers remain in the class list. This then needs to be removed one at a time.