Angular staff catalog copy location group filtering support

[Bill Erickson]

Wishlist / Evergreen 3.4

The Angular staff catalog needs support for search filtering on Copy Location Groups, consistent with the TPAC.

Plan for now is to integrate the groups into the org unit selector (via new component), replicating the functionality of the TPAC. If it would make more sense to render the groups differently for staff-specific use, feedback welcome.

[Bill Erickson (berick)]

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?

[Elizabeth Thomsen (et-8)]

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.

[Chrisy Schroth (cschroth)]

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.

[Jennifer Bruch (jbruchpails)]

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.

[Jennifer Weston (jweston)]

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

[Mike Rylander (mrylander)]

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.

[Michele Morgan (mmorgan)]

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.

[Michele Morgan (mmorgan)]

Changing Importance to High based on regression and staffcatalogblocker tags

[Jane Sandberg (sandbergja)]

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.

[Michele Morgan (mmorgan)]

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

[Jason Stephenson (jstephenson)]

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.

[Elaine Hardy (ehardy)]

+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.

[Terran McCanna (tmccanna)]

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.

[Michele Morgan (mmorgan)]

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.

[Joan Kranich (jkranich)]

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.

[Kathy Lussier (klussier)]

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.

[Joan Kranich (jkranich)]

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

[Bill Erickson (berick)]

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?

[Andrea Neiman (aneiman)]

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.

[Joan Kranich (jkranich)]

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.

[Michele Morgan (mmorgan)]

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.

[Michele Morgan (mmorgan)]

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

[Andrea Neiman (aneiman)]

See pullrequest on related bug 1949109

[Katie Greenleaf Martin (kgmspark)]

(we tested this at the same time we tested the work on 1949109)

I have tested this code and consent to signing off on it with my name, Katie Greenleaf Martin and my email address, <email address hidden>
PaILS is excited to have these visible in the staff catalog!

[Terran McCanna (tmccanna)]

Please clarify - is the fix for this incorporated as part of the fix for https://bugs.launchpad.net/evergreen/+bug/1949109?

(That one currently has some outstanding issues, so it has the needswork tag.)

[Katie Greenleaf Martin (kgmspark)]

Hello all - my understanding is that this bug (1861701) is for the COPY LOCATION groups and 1949109 is for the LIBRARY scoping groups (The Library Groups feature was added for 3.7 OPACs (TPAC & BOOPAC) in bug 1815815.)

We will need the developers to comment on how integrated the fixes are, but it looks like the issues are with the COPY LOCATION groups and not with the LIBRARY groups.

[Kathy Lussier (klussier)]

This bug reintroduces shelving location groups to the org selector in the Angular catalog, using a new component for that selector as berick first suggested when filing this bug. NOBLE has contracted with Jane Sandberg to do this work. It's included in the work described here - https://docs.google.com/document/d/1Aioe5GfQXHXrWVF90r_xdsbMhm1PjHP1vFOyyO0R3DY/edit?usp=sharing - and shared on the general list. The new component has already been created in bug 2062917

Bug 1949109 addresses both library scoping groups and shelving location groups in a selector that appears below the org selector. This will give Evergreen sites the option to include shelving location groups in either place depending on how those shelving location groups are used. There is more discussion about this work in the thread that starts here - http://list.evergreen-ils.org/pipermail/evergreen-general/2024-January/002358.html

It's a bit confusing.

[Andrea Neiman (aneiman)]

The branch on Bug 1949109 includes an alternative implementation of the org unit selector, hence my comment above in comment #23. It is up to the community to decide which path to take with the OU selector, but I think due to the refactoring on bug 2062917 they can't live together.

[Kathy Lussier (klussier)]

Andrea, I'm confused.

Why does the refactoring mean they can't live together?

[Andrea Neiman (aneiman)]

Kathy - sorry, based on my reading of your requirements on that bug I wasn't sure if they could live together? I'm happy to be wrong about that though.

[Kathy Lussier (klussier)]

We added it as an option to put the shelving location groups in the org selector. I'm pretty sure Jane has been closely monitoring the code on bug 1949109 , but I'll let her speak for herself if she sees any conflicts.

I didn't want to take away any of the flexibility for which Mike was advocating for those libraries that may not want to use the hierarchical structure that we need.

[Jane Sandberg (sandbergja)]

From some eyeballing, bug 2062917 and bug 1949109 likely have a small merge conflict between each other, but no fundamental differences.

[Andrea Neiman (aneiman)]

Thanks Jane & Kathy - I'm happy to be wrong about that and to allow people multiple choices!

We'll take a closer look at bug 2062917 next week as well and see if we can harmonize both branches & resolve the issues on ours.

[Andrea Neiman (aneiman)]

I am marking this duplicate of bug 1949109 since that's where the branch is. We will address feedback raised over there.