projectblacklight
Role masking for Site Admin
This allows Site Admin users to toggle between Exhibit Admin and Curator roles to see different views and permissions without having to create separate users. This is particularly useful when using an authentication system outside of Spotlight that does not permit the creation of mock users.
A migration was added to add a role_mask field to the spotlight_roles table. The Can Can ability.rb file has been edited to take into account the new role mask.
When a Site Administrator is logged in, a simple 'View As' menu appears on all screens under the navigation:
When a mask is in place, a notification appears in the same place with an option to clear:
The Exhibit Admin and Curator masks do not limit visibility to specific exhibits so all exhibits will still be available under the masks.
Thanks for the contribution @ives1227!
I've requested one of the designers (@ggeisler) to review this feature/implementation from the UI/UX perspective before we get too deep into code review (as it may change some of the underlying mechanics).
@ggeisler - I was waiting for feedback from our main administrator and trainer. The biggest use of this feature is for training and testing purposes without needing separate accounts. This is what she said:
"From what I gathered on a community call once, I think Stanford sets up all their exhibit owners with the Exhibit Admin role and they don't really use the Curator role. We've done the opposite where we only set up exhibit owners with the Curator role and they aren't even aware of the Exhibit Admin role and the functionality it contains since we take care of those pieces for them. So the masking feature would only be relevant to institutions who use the Spotlight roles like we do.
For us, it enables Super Admins to train exhibit owners with the Curator mask on (without having a separate user account) so we are all looking at the same admin UI during training. It also enables Super Admins to test Curator functionality (without having a separate user account). For example, the masking option came in handy when we found and created a fix for the Curator role not being able to upload thumbnails even though this functionality appears in the admin UI under that role. And we'll continue to use the masking feature as we make tweaks to the user roles in the future."
@ives1227: Thanks for passing on the feedback from your Spotlight administrator and trainer. I discussed this with a couple of the developers at Stanford back in the summer and neglected to write up our response to this. Apologies for that.
As your trainer mentions, you use Spotlight differently than we do in that you don't give exhibit owners admin access, only curator access. It sounds like this PR is primarily a solution intended to make training easier given your approach to restricting exhibit owners to curator-only access to their exhibits.
Our concern is that this solution adds a UI element that is somewhat obtrusive (in that site admins will see it on every page of the application) but at the same time not really useful for any institution that doesn't follow the same approach to Spotlight exhibit administration and training as you do (after five years and nearly 100 exhibits we haven't had a need for it). There's also quite a bit of code being added to the codebase for something that, again, might be of limited use beyond Harvard.
At Stanford we've added a fair amount of local Spotlight customization in our Exhibits repo (some examples also listed in this community roadmap spreadsheet), rather than contributing to the Spotlight repo, for features that we're not sure will be useful beyond Stanford. I wonder if this PR fits into that category, and should just be something that you maintain in your institutional Spotlight repo? If over time we discover that the larger Spotlight community is really looking for a feature like this, we could do some work to understand the details of what the community is looking for and revisit your implementation to see if it matches the broader need.
