Differentiated Tags course permissions disable Act-As for account roles wih otherwise correct permissions requiring Admin intervention

[hanleybrand]

The Differentiated Tags Permission set seems to disable Act As for custom created support/admin roles until it's explicitly granted. Canvas Support was able to figure it out with one of my colleagues yesterday, but since this was an unannounced change (as far as I can find, anyway) that disrupted work, I suspect this issue should count as a bug/issue, if not the specific case then the larger issue of non-obvious cascading effects from permission additions/changes breaking functionality of another permission.

Summary:

We began receiving complaints from college technical liaisons shortly after the 2024-11-06 deployment that followed the pattern "Masquerade is not working for our learning support staff (the button is gone) -- Were the permissions removed?"

Canvas Support found the solution (below, also it's in the title) before we did.

The permission option was committed about 3 weeks ago (probably not telling you anything new there), for the 2024-11-06 tag

canvas-lms/config/initializers/permissions_registry.rb

Line 1195 in 8ea85eb

manage_tags_add: {

Steps to replicate fix:

Canvas Support:

"After reviewing, we found that [support user] has a 'Sub-Account Support' role in the College of Public Health [sub account], while the user attempting to 'Act As' is a Teacher. The Teacher role has the 'Manage Differentiated Tags' permission, which the Sub-Account Support role lacks.

To be fair, we were checking the Act-As permissions and didn't notice the new permissions -- and, it's difficult to check account role permissions against course role permissions (although now I guess we know that this is something to do if Act-As breaks in the future)

Expected behavior:

I don't know about "expected" -- nobody expects the Spanish Inquisition -- the main thing I would hope for would be getting a heads up when Course/Account Permission changes were happening, especially if the change would affect other functionalities, especially if a change to Teachers is going to affect admin functions -- I can't find anything about this feature in the community docs (release notes or otherwise), and the Permission slide-out drawer in accounts/1/permissions lacks a description or 'What it does'/'additional considerations' section.

Additional notes:

I'm not sure what the optimal solution would be, but in the use cases I can come up with, but I don't see why our admin team wouldn't want to continuing allowing support people to masquerade as needed during support incidents because of a new Faculty feature.

Some ideas I had that are easy to have when I'm not the one implementing them:

• Adding a test with a custom Account role that has the Act-As permission and testing masquerading with new permissions/features, at least so that if it fails there's a data point to support mentioning the change in the release notes (i.e. that instance admins will have to manually add the new permission to custom roles)
• If possible, link a permission additions like this (e.g. those with linked Course/Account role permissions) to the Act As permission in addition to the specified Roles (i.e. the Act-As permission grants Differentiated Tags management)
• Alternatively, ignore the Differentiated Tags permissions when checking a user's role against a masquerade attempt (this seems like a less secure pattern compared to the former)