wishlist: add Library Groups to Angular Staff Catalog

[Andrea Neiman]

The Library Groups feature was added for 3.7 OPACs (TPAC & BOOPAC) in bug 1815815.

Since the Traditional Staff Catalog embeds the OPAC, you can use Library Groups via the staff client (for now); but Library Groups are not natively available in the Angular Staff Catalog.

This is a wishlist bug to add Library Groups to the Angular Staff Catalog.

[Scott Thomas (sthomas416)]

This is very important. I would really like to see it be elevated beyond mere Wishlist status.

[Nicole Romano (nicoleromano)]

With the upcoming merger and expansion of our library system (WAPI/PIKE to LC_LS, SUS and TUNK), it would be more streamlined for library staff to be able to search one area instead of choosing from multiple choices in the drop down menu.

[Andrea Neiman (aneiman)]

Equinox will be working on this under contract with PaILS, along with bug 1861701. 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.

[Mike Rylander (mrylander)]

I've pushed a newly rebased branch implementing this to:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups

The top 3 commits contain:
  * A refactoring of "fetch my lassos" from the OPAC
  * An initial UI addition for selecting lassos and location groups for staff search
  * Cleanup and improvement of the staff advanced filters, to better interoperate with lasso and location group searching

[Andrea Neiman (aneiman)]

This also addresses bug 1861701

[Katie Greenleaf Martin (kgmspark)]

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!

[Galen Charlton (gmc)]

A branch that adds Katie's signoff, fixes lint, and adds release notes is now avaialble as working/user/gmcharlt/lp1949109_signoff

[Kathy Lussier (klussier)]

We took a closer look at the code added to our dev server this afternoon and have a couple of comments questions. The dev server has our production data with many shelving location groups built at different levels of the org tree. We have no library groups in our production data.

1. Could you tell us how the shelving location groups are supposed to be sorted in the selector? When I have the OU selector set at the consortium level and then click the Shelving Location Group selector, I see three location groups owned by the consortium at the top of the selector followed by branch-owned groups with children's shelving locations that appear to be alphabetically sorted.

See screenshot at https://pasteboard.co/vlzd1MTduGcQ.png

However, as I scroll down the selector, I see one more branch-owned shelving location group followed by a consortium-owned group for our public libraries, followed by a branch-owned group, followed by another consortium-owned group for our academic libraries, followed by a bunch of branch-owned groups for adult and teen collections.

I suspect the sort order is by ID. I would think a better sort order would be Consortium-owned followed by system-owned followed by branch-owned with each shelving location group alphabetically sorted within each of those groups. However, I have no idea of how these groups should be sorted in a selector that mixes library groups with shelving location groups.
,
2. When I select an OU from the org unit selector (example Beverly), the Shelving Location Group selector populates to only show shelving location groups owned by Beverly, a parent OU of Beverly, or a child OU of Beverly. This selector shows the "Academic Libraries" option because it is owned by the consortium, which is a parent of Beverly. However, Beverly does not own any shelving locations in that group. The academic libraries shelving location group is made up of locations owned by systems and branches that are unaffiliated with Beverly; there are no consortium-owned locations in that location group. My expectation is that a shelving location group would only display if the selected OU, a child of the selected OU or maybe even a parent of the selected OU owned a shelving location in that group. Is there a use case I'm missing where selecting Beverly as an OU should provide an option where there is no possibility Beverly items will be included in the results?

3. If I select Beverly in the OU selector and then children's collections in the shelving location group selector, my expectation is that I will retrieve items that match both conditions. However, I retrieve all items from the children's collections shelving location group regardless of which OU's own it.

[Galen Charlton (gmc)]

The intended sort order of the shelving location groups is by position, then by name. The position applies across all shelving location groups owned by the fullpath of the context OU.

[Kathy Lussier (klussier)]

OK, that's helpful to know and explains some of the funky order I'm seeing, but the sorting still appears to be off. With that information in hand, we'll try to pinpoint where we are seeing problems. Thanks Galen!

[Michele Morgan (mmorgan)]

We did some more testing with both our production data and a concerto test system with additional shelving location groups added. The order of the shelving location groups does not seem to be following position, then name as intended. Instead, the sort appears to be by the database id in asset.copy_location_group.

An example from the concerto test system:

With the following entries in asset.copy_location_group:

 id | name | owner | pos | top | opac_visible
----+---------------------------+-------+-----+-----+--------------
  1 | Juvenile Collection | 2 | 0 | f | t
  2 | Local Interest Collection | 3 | 0 | f | t
  3 | Adult Collections | 1 | 3 | f | t
  4 | Children's Collections | 1 | 1 | f | t
  5 | Teen Collections | 1 | 2 | f | t
  6 | BR1 Teen | 4 | 2 | f | t
  7 | BR1 Children's | 4 | 1 | f | t
  8 | BR1 Adult | 4 | 3 | f | t

The position then name sort would be:

 id | name | owner | pos | top | opac_visible
----+---------------------------+-------+-----+-----+--------------
  1 | Juvenile Collection | 2 | 0 | f | t
  2 | Local Interest Collection | 3 | 0 | f | t
  7 | BR1 Children's | 4 | 1 | f | t
  4 | Children's Collections | 1 | 1 | f | t
  6 | BR1 Teen | 4 | 2 | f | t
  5 | Teen Collections | 1 | 2 | f | t
  3 | Adult Collections | 1 | 3 | f | t
  8 | BR1 Adult | 4 | 3 | f | t

The dropdown in the angular catalog appears as follows:

Searching CONS

Library Groups
 Non-Branches
Shelving Location Groups
 Juvenile Collection
 Local Interest Collection
 Adult Collection
 Children's Collection
 Teen Collection
 BR1 Teen
 BR1 Children's
 BR1 Adult

Searching BR1

Library Groups
 Non-Branches
Shelving Location Groups
 Juvenile Collection
 Adult Collection
 Children's Collection
 Teen Collection
 BR1 Teen
 BR1 Children's
 BR1 Adult

Searching BR2

Library Groups
 Even Branches
 Non-Branches
Shelving Location Groups
 Juvenile Collection
 Adult Collection
 Children's Collection
 Teen Collection

[Terran McCanna (tmccanna)]

Removing signoff as per comments 8-11

[Katie Greenleaf Martin (kgmspark)]

Hello all - my understanding is that bug (1861701) is for the COPY LOCATION groups and THIS bug (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)]

Hi Katie!

With the code loaded, that selector is indeed showing shelving location groups. Mike's comment #4 and Galen's comment #9 above also indicate that shelving location groups are included in this code. It's true that NOBLE isn't planning to use this component for shelving location groups, but we spent some time testing it to make sure it worked as expected for others that may use it for that purpose.

[Andrea Neiman (aneiman)]

Confirming that code for this and bug 1861701 are on the same branch linked above. I did not mark 1861701 as duplicate because to my reading, that bug included other concerns. I can mark it duplicate if that's easier / cleaner from LP's standpoint.

We will look at the issues raised in the above feedback.

[Andrea Neiman (aneiman)]

I have gone ahead and marked 1861701 as duplicate for LP housekeeping purposes. We will post an updated branch for this bug & 1861701 addressing feedback above.

[Kathy Lussier (klussier)]

Andrea, I'm confused as to why bug 1861701 is marked as a duplicate when that bug addresses adding shelving location groups to the library selector and there will be a branch forthcoming from Jane to add that option. I think there may be a misunderstanding as to what the NOBLE development is doing.

The separate component bug that we were talking about yesterday is the first step, but there will be follow-up code that we were planning to post to bug 1861701. Or should we be posting it elsewhere?

[Jane Sandberg (sandbergja)]

FWIW, I was thinking that bug 2032665 that Michele posted would be a good home for the shelving-location-groups-in-library-selector implementation, and bug 1861701 (and hence this bug) could be the shelving-location-groups-outside-the-library-selector home.

[Kathy Lussier (klussier)]

Ah, ok! I think that was the missing piece from my perspective. I had forgotten that one was out there. Carry on.

[Andrea Neiman (aneiman)]

Yes, my apologies - confirming Jane's and my ongoing mind-meld from this week. I believe all parts of 1861701 are either covered here (1949109) or the pending 2032665.

[Mike Rylander (mrylander)]

Regarding the sorting mentioned in 8 (and followups) and detailed very helpfully in 9, it looks like there's a bug with the simpler sort syntax in cstore/pcrud. Specifically, this should sort by the pos column, then the name column:

  {order_by:{acplg:['pos','name']}}

but it does not. However, the more verbose spelling of that:

  {order_by:[{class:"acplg",field:"pos"},{class:"acplg",field:"name"}]}

works just fine. So does this very old spelling that just uses whatever the caller provides (with SQL injection protections, mind you), but it's bad form and we should remove it:

  {order_by:{acplg:'pos, name'}}

Branch update coming soon to address that.

[Mike Rylander (mrylander)]

I've pushed a branch to https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups-sort-fix-REBASE that fixes the sort issue for location groups, and also rebases the commits atop current main.

[Mike Rylander (mrylander)]

Regarding comment 11, points 2 and 3, I'll take point 3 first as it's simpler.

That is the intended behavior -- when a library group or shelving location group is selected, it /replaces/ the library as the "locus" of the search -- the library provides the context, the group (library or location) provides the item grouping axis outside the org hierarchy. Otherwise it would be impossible to use the whole group as a separate, non-hierarchical search axis.

With the intent re point 3 in mind, regarding part 2, I can certainly see an argument for loading only those location groups owned at-or-below the context org, and not including those owned "above" the context org. Unfortunately, the semantics of location groups are (to put it mildly) muddy, and not well documented with regard to their natural non-hierarchical behavior. In particular, there are semantically conflicting commit messages from the initial introduction of location groups regarding what they mean (actual search locus vs display-only modification) in different interfaces, and the query logic is ... complicated, especially WRT Located URIs vs location groups and lassos.

I say all of this as background; I know there are ongoing discussions and even new feature plans/developments that make their own assumptions about the details of the semantics of location groups (and lassos), but /this/ branch uses the above-described assumptions to implement the staff catalog version of those.

Thanks!

[Kathy Lussier (klussier)]

Thanks for responding to those two questions, Mike! The intended behavior certainly wouldn't work for our implementation of Shelving Location Groups, but that's not a barrier since we plan to use the option Jane is working on to re-add it to the library selector.

Michele is planning to load the patch on some test servers so that we can check out the sorting issue.

Have a nice weekend!