In Permissions, Separate "Add/remove students for the course" into 2 permissions

[cms_hickss]

This idea has been developed and deployed to Canvas

---

Please change each the "Add/remove students for the course" from a single setting to two separate settings.

Current:

Add/remove students for the course

Should become:

• Add students to a course
• Remove students from a course

Per Cosme Salazar in More granular permissions for admins and In Permissions, Change "ADD, EDIT, and DELETE" into Three Separate Settings I have divided out the multiple functionality settings into their own requests. There are now 10 separate requests.

[millerjm]

This is a huge problem for us. 

There is another permission bundled with this one, which is the ability to view prior enrollments on the people page.  They have to have the permission to add students in order to view prior enrollments.  We had to give the permission to add/delete to faculty so that they could view this data for federal financial aid reporting of last date of attendance.  We then had to do a javascript override to hide the button from anyone except for admins, which is a hack and doesn't always hide it, or it hides it from admins sometimes but not always, while using firefox.  We would like the prior enrollment activity data to be viewable to faculty just like the currently enrolled student data, without them having the ability to add/delete students. 

We need some faculty to be able to add and/or remove students in some subaccounts.  Having the flexibility to do this would alleviate some of the work that our office has to do because these permissions are bundled and ensure that this security is actually secure, since the javascript hack is not a secure fix. 

[csalazar]

We generally have a high bar for adding new permissions as they increase the complexity and cost to implement new features. I think the most compelling argument in this thread is by  @gladysie ​ regarding what permission allows a user to view SIS information (and how it should be managed by the "Read SIS Data" permission).

Are there other reasons certain users need to be able to add a user to a course but not remove the same student from the same course? If not, I'm inclined to archive this issue.

[cms_hickss]

Deactivated user​ not all classes are purely academic in nature. Some are for support (and probation) or pre and post testing. Those students need to be ADDED but never DELETED so that the record of their interactions is easily found by all those who have access to those courses.

If you delete them, there is no proof the student was in that course (as not everyone has access to logs and page views) unless you add them back and their activities return.

Also, this Idea has nothing to do with reading SIS Data (which is a BUG with the current set of permissions). This has to do with Teachers, Course Designers, and TAs adding and/or deleting a student from a course.

[cms_hickss]

Deactivated user​ you said:

​"We generally have a high bar for adding new permissions as they increase the complexity and cost to implement new features."

Please explain what you/Canvas mean by a "high bar"? Is it how many users are impacted? How many institutions? Also, how does it, if it does, relate to user votes and comments on an Idea? When my director asks me what that means, I'm going to need an answer as defined by your team.

[millerjm]

I agree with everything that cms_hickss said in her post above.

We also have some classes that are not purely academic.  They could be managed manually or perhaps it could be managed via SIS, depends on the use case.  If the student is removed from the course, then the instructor loses all data related to the student unless the student is reinstated. 

Faculty will also do all kinds of weird things if they have access to. If there is a button to click on or an option to check, they will find it and then wonder why it's messed up. 

We want to be able to control who has access to +People - so who can add students, and who can add teachers, etc to the class.

We also want to be able to control who can edit a user separately from who can inactivate/delete a user from the course:

Hope that makes sense.

[Jeff_F]

Thanks for the smile, re: "...they will find it and then and wonder why its messed up."

[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. 

[snugent]

As many have pointed out here having the Read SIS data permission tied to the Add/remove students is problematic. I think there are several use cases.

Custom roles - Creating custom roles and applying permissions as desired with the right level of access. People who support teachers and students need access to this data to help troubleshoot issues.

Teacher role - They need to see SIS data to make sure this matches the enrollment is the SIS(Datatel) roster. We don't want instructors adding/dropping students from Canvas since enrollment happens officially through the SIS.

In terms of cost for us, it means people in the teacher role in our system do not have access to some data that is helpful to their jobs. We are small institution so it doesn't impact us as much as it does for larger institutions. I can see how this can quickly become nightmare. For us the limitation means we probably won't expand our use of Canvas for other things until we have better permissions in place.

[Jeff_F]

Big hug/ high five for mentioning this about the Read SIS data permission.