search

projectblacklight / spotlight

Spotlight enables librarians, curators, and others who are responsible for digital collections to create attractive, feature-rich websites that highlight these collections.
Other
160 stars 64 forks source link

Allow exhibit admins to determine if the default email address should receive feedback #1873

Open jkeck opened 6 years ago

jkeck commented 6 years ago

Currently, if the person who configured the Spotlight site chooses to configure an email address to receive all feedback, the exhibit administrator does not have the choice to modify the behavior. We have a local use case where we want to allow Exhibit administrators to disable this behavior for their particular exhibit if they choose.

An initial thought, if we need this to be exhibit specific is to add a config option to the exhibit admin interface to allow an exhibit administrator to disable the email going to the default address.

ggeisler commented 6 years ago

The mockup below suggests adding a new checkbox and associated hint text below the current "Add new contact" button and hint text (see red arrow in mockup). The checkbox is unchecked by default, so shouldn't affect current exhibits, and if left untouched in new exhibits, shouldn't change any current behavior.

If, however, the checkbox is checked, we should modify the current feedback email behavior and only send the feedback submissions for that exhibit to the verified email addresses on the configuration page. Any email addresses configured as part of the basic Spotlight site configuration would be excluded from feedback submissions for this exhibit.

However, as @jkeck as I discussed over Slack, exposing this option to exhibit administrators does open up the potential for unintended consequences, as an admin could check this box without fully understanding the implications (not all admins will understand the purpose and existence of the "default email addresses" not shown on the page). And there isn't an obvious way site superadmins (such as the Spotlight service team, in the SUL case) would know if an exhibit admin has decided to check this option. So feedback from an exhibit where the exhibit admin has checked this checkbox could go unseen by the service team, possibly without their knowledge.

Although we might not have a pattern for this yet in the admin interface, a potentially straightforward solution to this is to only show the checkbox and associated hint text if the user is a superadmin; regular exhibit admins would not see it. Given the use of this checkbox is probably an exceptional case (at least for SUL, it's only come up now, after 50 previous exhibits), requiring the user to be a superadmin to use it might be reasonable?

spotlight_graffle__config___disable_default_contact_email
jkeck commented 6 years ago

This looks good to me. The question that comes to mind looking at this is should we create some sort of site-wide admin UI that allows a superadmin to set the email address/functionality (as opposed to being in configuration code as it is now).

I think these stand as totally separate pieces of functionality, so I don't think that should block us moving forward on this in anyway.

I was concerned about our current approach and just setting a flag on the exhibit object, but after looking closer at some of the CanCan Docs, I realize that we don't necessarily need to split the site-wide feedback email into a separate resource in order to ensure authorization could be enforced by CanCan properly.

ggeisler commented 6 years ago

The question that comes to mind looking at this is should we create some sort of site-wide admin UI that allows a superadmin to set the email address/functionality (as opposed to being in configuration code as it is now).

Yeah, that seems like it would be pretty straightforward and a nice addition. The biggest issue might just be where that default email address input lives within the superadmin pages. It might require a new page, or relabeling an existing page (e.g., the Customize appearance page is the best existing place for it, but it isn't an "appearance" thing).

I have an existing design for another addition to the the superadmin pages (though that one is SUL-specific) so maybe we can tackle those and possibly other superadmin-related tickets as a group at a future time, and just implement the design in this ticket now so we have it in the near-term for Parker.