Angular staff catalog copy location group filtering support

Pausing this pending feedback.

The org unit selector in the staff catalog acts as a single org selector for all of the search types (Keyword, Identifier, Browse, etc.). Extending the shared org selector to include copy location groups only makes sense on the Keyword search tab, since other search types don't support that level of filtering.

One option would be to display the location group + org units selector on the Keyword tab only, displaying the stock org selector on the other search tabs.

My impression of copy location groups is they are primarily a patron search tool, though, so maybe they don't need that level of staff visibility? Would it make more sense to put them down in the extra filters section (e.g. beside the copy location selector)?

Or to put it another way, do staff use copy location group filters?

I don't think there are any catalog search options that are only used by patrons and not staff, since staff do everything that patrons do (plus more) and are often working on behalf of patrons. How much people use Copy Location Groups probably depends on how many a system has and what they are used for, but we use them a lot in NOBLE. All public libraries have copy location scopes for their adult, teen and children's collections, and we also have scopes for All Children's, All Teen, All Adult, All Public Libraries and All Academic Libraries. We created them specifically to be used as search scopes, and we need them in the staff catalog as much if not more in the staff catalog.

I can agree with Elizabeth 100%, staff at our library use the copy location scopes constantly. I just realized this bug this week when I tried again to catalog using the Staff Catalog (Experimental) in 3-4-6 and couldn't find them. I just asked our System Admin and he pointed out this bug to me after we looked for it in the system and talked about where we think it might be supposed to be showing up at.

We have quite a few of these configured both for use by patrons, and also for groupings that staff have requested to make our work easier. In our current catalog they show up under the drop down menu for "Search library", although they aren't truly "libraries", but we thought maybe they were supposed to be where the Experimental catalog has "All copy locations" (and nothing else). Sadly, at this point I have mostly abandoned the Experimental catalog until I have to use it, as it's just making my job more difficult.

I can also agree on behalf of the PaILS/SPARK libraries that this functionality would be greatly appreciated by library staff. The often complex Resource Sharing relationships that arise in a growing consortium can result in staff having to know which individual libraries they are able to resource share with and do multiple searches for holdable materials on the behalf of a patron.

The groups searching for staff would greatly simplify down their workflow.

Discussion in CWG is unanimous in the desire to have this functionality for staff for all reasons stated here.

FWIW, I think this may be an opportunity to provide a staff-oriented interface that deviates a little from how the TPAC does things, especially now that library groups (lassos) are back.

A new dependent selector that just presents location groups and library groups based on the currently selected org unit would avoid complicating the org unit selector component. It could be reasonably populated on-demand in the Angular catalog, where TPAC coding style prevents that and makes the UX harder to manage for multiple dependent dropdowns.

Based on the feedback confirming that staff users use copy location group filters just as patrons do, I'm marking Confirmed and removing the needsdiscussion tag.

Also adding a regression tag and removing the Wishlist designation since, prior to the Angular catalog, staff users had this ability while searching the catalog in the staff client.

Changing Importance to High based on regression and staffcatalogblocker tags

Terran, Michele and I were talking about this bug today. We thought a good path forward would be to add a new dropdown to the angular staff search that mimics the functionality of the "Where" dropdown in the boopac advanced search. It appears to have both lassos and shelving location groups.

After some more thought, there are good arguments for having a library selector in the angular staff catalog that is separate from the selector that appears on other Angular pages in Evergreen where only the pure list of org units is appropriate.

Some examples are:

bug 1910773 - Angular Staff Catalog does not observe Custom Org Unit Trees or Org Units Do Not Inherit Visibilty global flag

bug 1849497 - Hide specific org units from staff catalog search results

bug 1949109 - wishlist: add Library Groups to Angular Staff Catalog

Also worth mentioning, the "Where" selector in the Bootstrap catalog isn't a good model in its current state. See bug 1970476

I privately questioned the existence of a separate staff catalog from the beginning. I'll question it publicly now.

Why do we need it? Shouldn't staff and patrons see pretty much the same thing? That was one of the things that library staff at MVLC liked about our migration to Evergreen from their prior ILS. The staff previously had to switch applications to see what patrons see in the catalog.

CWMARS library staff are dissatisfied with the lack of search parity between the two catalogs.

NB: I am speaking for myself/from my personal experience here. Don't take this opinion as an official position from MVLC nor from CWMARS.

+1

One of the things staff requested when we developed Evergreen was the ability to see what patrons were seeing without having to log out. Having the same view and the same search filters is often key when troubleshooting.

Throwing in my contradictory opinion: The 4 different ILSes I worked with in circulation and reference prior to coming to an Evergreen library all had markedly different staff and patron catalog interfaces and I never found it to be a problem -- but that is also what I was used to. When walking a patron through a search either in person or on the phone, I would use the public interface to demonstrate. When working with other circ staff in earlier versions of Evergreen I found they often found it *more* confusing to have the same interface where they could see more information than the patron because they wouldn't always realize the patron couldn't see everything they were seeing.

More specific to current Evergreen, the Angular staff catalog is significantly faster both in returning search results and especially in displaying record details. I'm not sure of all of the factors that influence that, but not needing to load added content from a third party site is certainly beneficial.

Since the last comment on this bug was posted, a fix for bug 1970476 was released on 5/19/23 and is live in 3.9.3, 3.10.2 and beyond. This fix added location groups and library groups to the Org Unit selector in the Bootstrap Catalog.

The attached screenshot shows the org unit selector in the Bootstrap catalog in a stock Evergreen system circa 3.9.3, 3.10.2, 3.11. Note that the stock Library Group "Non-branches", and the stock Shelving Location Group "Local Interest Collection" are both available in the selector.

This seems like a good precedent. Using this same approach to resolve this bug would also resolve bug 1949109, and potentially other bugs mentioned in Comment #10.

C/W MARS uses Shelving Location Groups. I agree the groups should display in the org unit selector. The org unit selector in the Bootstrap Catalog displays on each screen as the patron does searches and can be helpful in narrowing the search. I agree with using the same approach in the staff catalog.

I would like to go back to berick's comment #1 where he said "...other search types don't support that level of filtering."

In tpac, copy location group filtering works on all search types. Does search in the Angular catalog handle search in a different way that prevents this level of filtering? If so, would it take a lot of effort to get this level of filtering to work?

We have prioritized the library selector issues for development, and I'm trying to get a handle on the scale of this work. I'm pretty sure our libraries will expect the filtering to work on all search types when this functionality is reintroduced.

Our libraries will also expect the filtering to work on all search types and for the location groups to display on all search screens.

The Angular catalog uses the same APIs.

I didn't realize the OPAC displayed the copy location group in all of the search interfaces or that so many of the APIs supported location group filtering.

There are some outliers, though, where it's in the UI but does nothing (Item barcode searching, for example) and in the case of browse, selecting a copy location group in current main produces a Postgres error for me. (This may be a new bug, though. Working for others?).

In any event, is the solution just to create a combo org / copy location group select component, display it everywhere in the staff catalog, and any time it's not supported for a certain API, ignore it / treat it like a plain org unit filter?

Equinox will be working on this under contract with PaILS, along with bug 1949109. Here is the SOW for this project:

* Equinox will add existing Library Groups and Shelving Location Groups search filter functionality to the Angular Staff Catalog. Both sets of groups will be shown in a single new combobox within the advanced staff search interface.

* Equinox will also make the show / hide toggle to the advanced staff search interface more obvious than the existing ‘kebab’ link and will further fix the ‘hide’ part of this toggle so it is functional.

Chrome and Firefox

I tested 3.7.4 and 3.10.2. Searching in the OPAC by barcode in the numeric search filtering to a shelving location group works. If the item belonging to the barcode is in a shelving location that is not part of the shelving location group, it displays: Sorry, no entries were found for your search.

Searching Browse the Catalog filtering by a shelving location group does not show any results. No error, no message, just no results populated to the screen.

Creating an org unit selector list of org units and shelving location groups sorted alphabetically on each search screen would be good. Copying the same list that we have in the OPAC to the staff catalog screens would be a solution as recommended in comments #14 and #15.

Aside from the work that Equinox and PaILS will be doing to address this (see comment #19), we would also like to see the combo org / shelving location selector approach for the staff catalog as described by Bill in comment #19.

We will file a separate bug for that functionality.

Bug 2032665 has been opened to address restoring shelving location groups to the org selector.