Site Level Showcase Roles
We are a consortium whose libraries SHOULD be able to manage their own showcases but should NOT be able to manage each others' showcases. Only we should be able to have system-wide showcase admin privileges. However, there is currently no showcase admin role at the collection site level, which means that we can't assign the showcase admin role to ANY of our libraries' staff users, since the current showcase admin role is simply too broad and all-encompassing. So we are left managing all our libraries' showcase admin tasks ourselves, which is less than ideal.
To be clear, we don't have an issue with all our libraries' showcases displaying in each others' collection sites when patrons perform searches (if that's what they want - it should be up to them). We are simply asking for there to be a showcase admin role at the collection site level so they can manage their own showcases, and only their own showcases.
Please comment on the following options for a Site Level Showcase Management feature:
What is the Problem we're solving and why?
Vega Consortia Libraries and Multi-Library Organizations would like to be able to manage showcase admin access by site. Site Level Showcase Admin Users should be able to quickly filter available showcases to those created in their Collection Site as well as retain view and use access to all showcases created by librarians in their organization.
Job Stories:
- As a Site Admin, I can assign Showcase Creators and Admins for specific sites, that are limited to creating and editing showcases in a particular site(s).
- As a Site Admin or Content Admin User, I can use the Home Page tools to filter, view, search, and find showcases that were made in the current Collection Site I am editing the Home Page display for.
- As a Site Level Showcase Creator or Admin, I can only access the Showcase tab when logged into the site(s) I have permissions in.
- As a Site Level Showcase Admin, I can edit Showcases that were created in my site.
- As a Site Level Showcase Admin, I cannot edit Showcases that were created in sites I do not have permissions for but I can view and use these showcases.
- As a Staff Showcase Creator or Admin, I can use the Showcases tab to filter, view, search, and find showcases that were made in the current Collection Site I am logged into.
-
Kristine den Boon
commented
#1 - As a overall site admin, I would like to be able to assign a collection site admin (for showcases) who could then assign sub-creators themselves. These showcases would just be for their collection site.
#2 - Yes!
#3 - Yes!
#4 - Yes! Especially useful for if a staff member is no longer working there and their showcases need editing.
#5 - Sure! But then to be able to publish them on your site without it affecting the other collection sites.
#6 - Yep!Ultimately, what I would like to see happen is that Showcases are created by staff for their site, and are published to their site only. These showcases are viewable in the CMS by staff at other sites to be copied over and then published on their site. What I want to avoid is similar showcases being created by staff at multiple sites, thereby clogging up a resource card with showcases that are all the same (i.e. a read-alike showcase for a popular book created by five different sites with only minor differences).
-
Margaret Rose O'Keefe
commented
I am going to vote for Kathryn's idea too - that would be a great addition to this process!
-
Kathryn Brew
commented
1. Yes and no. Site Admins should be able to create Site Showcase Admins. Site Showcase Admins should be restricted to their own library’s showcases - but I would prefer them to be able to use any site. I don’t see why showcase creation (drafting) should be limited to site.
2. Yes, Site Admins and Site Homepage Content Admins should be able to filter, view, search, and find their location’s showcases - and also be able to view, search, find, and use any showcases from the consortium.
3. As a Site Showcase Creator or Site Showcase Admin, I would prefer to access the Showcases tab anywhere. But I should only be able to do things with the showcases created by other users of my site(s).
4, 5, and 6. Yes for the permissions around editing/viewing/using/filtering. I would still prefer a different way to identify these showcases than where they were created. (My suggestion? https://ideas.iii.com/forums/951766-vega-discover/suggestions/48825764-staff-user-accounts-add-library-organization-fiel).
-
Margaret Rose O'Keefe
commented
#1 Yes, collection site admins should be allowed to assign showcase roles to their existing staff users for their own collection site.
#2 Yes, this would be helpful.
#3 No, they should be able to access the showcases tab and view system-wide showcases at any time, they just shouldn't be able to edit/delete/publish showcases that don't belong to their collection site, and they should only be able to do this for their own collection site if they're a site-level showcase admin.
#4 Yes.
#5 Yes.
#6 I am not sure what a "Staff" Showcase Creator or Admin is as opposed to a site-level one, but this sounds like a good option for anyone, as long as they can also see the system-wide view too.I think staff will often log in to our main site at the system-level and create showcases, even though they will also log into their own collection sites sometimes too. Perhaps if there were a message upon showcase creation about where it would appear, who it would be accessible to, etc. and even a choice as to whether they want to limit visibility or access to the collection site where they're logged in, if relevant, that would be helpful, rather than requiring them to be logged in one place or another to achieve certain results. Also, for showcases that are limited to their own collection site, an option after the fact to open up access to system-wide might be helpful if they change their mind later. (Just some ideas for what might help in a consortium - hope that makes sense.)
-
Elias Rosner
commented
This would be really helpful! Right now we don't do a lot of collection showcase changes at the library level because of the headache of having to ask every time one needs to be added or removed.