Summer 2023 - Locations and Service Points

Module: ui-service points

There is a FOLIO UI module called ui-servicepoints. https://folio-org.atlassian.net/projects/UISP/summary

What this module controls is the display of service point information in the top right corner for the logged in FOLIO user, and the modal that controls allowing users to switch logged-in service points if they have more than one attached to their user account.

For the PO in this role, this normally only comes up if there are bugs found with people switching service points, in which case you will be the PO to investigate and shepherd the bug through troubleshooting. Beyond that, there really are no functional features in that area of FOLIO to work on. The code does get maintained, but the work is generally done by Stripes Force as part of general maintenance of the Stripes infrastructure.

Responsible dev teams

It's always good to double-check on the FOLIO Module/JIRA project-Team-PO-Dev Lead responsibility matrix as this stuff does move around.

The primary thing to keep in mind is that ui-tenant-settings is owned by Firebird, while mod-inventory is owned by Folijet and mod-inventory-storage is owned by Spitfire.

That means that if you are working on a feature that requires both front and back-end work, you have to work with two different teams (at the very least to coordinate code approvals and testing.)

PO coverage history

Cate Boerema was PO from beginning of project work to December 2020. Erin Nettifee was PO from January 2021 to August 2023.

Even though functionally this area of FOLIO is part of an inventory module, the POs responsible for this area have historically been part of the Circulation PO group and engaged with the Resource Access SIG through meetings.

Slack channels / history to be aware of

During Erin's tenure, most discussion around locations and service points happened in #resource-access and #metadata-management, with one exception. To engage in specific discussion about implementing effective holdings location, Erin used a separate slack channel named #holdings-without-items. That channel is archived in Slack, but it can be pulled back up by searching for the channel name.

(Note that the channel name might imply that the effective holdings location is only calculated if there is no item record; that is not actually how it was developed, the effective holdings location lives on the holdings record regardless of whether an item record is attached to the holding.)

Open issues in Summer 2023

This list outlines information to know about jiras in the service points and locations epic, including context for features that have not yet been developed. The departing PO may indicate opinions about how certain features should be developed in the future, but those are only opinions and not necessarily project decisions.

• UXPROD-1562 - Mark Service Point Inactive
  • The use case here is that libraries need some way to get rid of a service point no longer in use. Currently that can be done with an API call to the service points endpoint, but that endpoint does not check any dependencies, so that can be dangerous, especially if the library is in production.
  • Early production discussions under Cate landed on the idea of marking a no-longer-used SP inactive, so that it could be removed in various UI places but that you would not have to come up with logic to handle a deleted service point when references might be all of the place in FOLIO data.
  • The primary stakeholder here is going to be RA, though service points also show up in Inventory and in Users. But Users really is almost a sub-SIG of RA in terms of the overlap of issues (in Erin's opinion.)
• UXPROD-2367
  • This is an old ticket from early on in the project. The root is that FOLIO does not enforce any conventions on codes in the location tree, but normalization occurs in the circulation rules editor, such that "Primary Stacks" and "primary-stacks" would both normalize to "primary-stacks" as a code and break things, potentially.
  • In practice, I think this has not been painful for libraries and thus has not bubbled up as needing a fix because the circ rule UI has a pop-up location chooser such that you go down the location tree to pick the one you want to use, which lessens the risk of typing in something for Library A and accidentally referencing Library B. Also, the circ rules store the location UUID, not the code.
  • The workaround is to tell people when configuring FOLIO to be aware of this gap, but honestly it may be better long term for the project to change the FOLIO UI editor to use FOLIO names instead of codes.
• UXPROD-3587
  • This Jira is about the use case of needing pickup locations that are only available for library staff, and not for patrons.
  • This would provide a lot of value-add, though the work on UXPROD-2689 could overlap with the use cases here. Eg, if I'm working on an item, and I put a temp loan type on the item of "in repair", I can write a circ rule such that items that are in-repair can only be requested to move to a staff only pickup location. But, that doesn't address the issue of hiding pickup locations from discovery.
• UXPROD-4054
  • This is a ticket that has use cases both for discovery and for controlled digital lending systems. For controlled digital lending, you need to be able to know that a particular location is a closed stack so that you can move a physical copy to that location while the digital copy is in circulation. For discovery, it matters to be able to tell patrons if they can actually physically get to a book or browse the shelves where a book is located. 
  • I'm not aware of active FOLIO work around special collections support, but this is an obvious thing that could help a library with special collections too.

Others to be aware of
UXPROD-3213 - Getting issue details... STATUS

UXPROD-2156 - Getting issue details... STATUS

UXPROD-1007 - Getting issue details... STATUS

• I lost track of this because Darcy (former PO) put it in the Notices Epic instead of the location one, but this one probably should be worked sooner rather than later.