Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Use LocationID to determine agency

Description

Current situation

When introducing suppression by shelf location for Polaris libraries, the capability to identify agencies by LocationID was removed. This story is to reintroduce LocationIDto affiliate a branch (via the value in LocationID) to an agency. As part of this effort, we also need to clarify the role of shelf location and agency.

LocationID is the branch location identifier exposed via the Polaris API for item records. The LocationID is populated by the associated OrganizationID. OrganizationID's are used to identify the system (e.g. RIVERSHARE), the library (e.g. Davenport) and the branch (e.g. Fairmont) in Polaris records and, for our purposes, used to populate both the item record owning branch (which branch owns the item) and assigned branch (where the item currently resides).

Assumptions

  • LocationID is the only data element procured from the corresponding API method needed to determine agency affiliation.

  • ShelfLocation will no longer be used to determine agency affiliation.

  • LocationID to agency mappings stored in the DCB hub will be used to associate LocationID to agency code.

  • A given LocationID can only be affiliated with one agency code but one agency code can have many LocationIDs.

Requirements

  • If LocationID is null in a Polaris item record, then do not associate the item with an agency.

  • If LocationID is found in a Polaris item record but the LocationID is not mapped to an agency, then do not associate the item with an agency.

  • Any item not explicitly affiliated with an agency will not be displayable in Locate DCB and will not be selectable for requests.

  • An item with a LocationID mapped to an agency will be displayable in Locate DCB and subject to availability and selectability criteria.

  • LocationName must be displayed in Locate DCB’s summary holdings Location field (see attached). Currently, this displays the Polaris ShelfLocation. [It is ok to strike this requirement from this story in lieu of creating a new story]

In Scope

  • Polaris LMS

Out of Scope

  • DCB admin module changes would fall under a different Jira.

Activity

Show:

Tim Auger March 25, 2025 at 4:25 PM

Tested across the board for all member libraries. Corresponding configuration updated in staging and production.

Jag Goraya February 17, 2025 at 2:36 PM

Via on commit commit 0853448:

Adds the optional capability for the Polaris client to use LocationId per DCB-1675 as a strategy for resolving an item agency whilst retaining the current code strategy as a default.

Notes:

Behaviour is set via the HostLMS setting clientConfig.item.item-agency-resolution-method which defaults to "Legacy" (The current behaviour). Correct function of LocationId strategy depends upon the presence of mappings (direct_mappings.tsv) which map LocationId as a string to agency. For exmaple:

fromContext fromCategory fromValue toContext toCategory toValue

RIVERSHARE Location 16 DCB AGENCY 6davn

It is crucially important to remember that when resolving an agency as a part of the Search/RTAC flow the HostLMS adapter used will be the "Catalog" role. For instances of locate based on a shared system, this will be the HostLMS of the "Shared" system, and NOT the "Circulation" LMS for each library. Note also that the fromContext in this scenario is the shared system not the target library - as we are trying to derive from a shared system which of the member libraries a given item belongs to.

When LocationID agency resolution is enabled the concept of "Default Agency" for Polaris systems is not used when mapping items - we either know the agency explicitly or we don't and whilst we will return information about the item, we cannot use it in subsequent flows.

 

Options for clientConfig.item.item-agency-resolution-method are:

case "LocationId" -> enrichItemWithAgencyUsingLocationId(itemGetRow, item, hostLmsCode); case "Legacy" -> legacyEnrichItemWithAgency(item, hostLmsCode); default -> Mono.just(item);

 

to apply this now, do we need to

  1. explicitly set clientConfig.item.item-agency-resolution-method for the RIVERSHARE host lms to “LocationID”?

  2. explicityly make no changes to the DAVENPORT and BETTENDORF host lms config?

  3. optionally set that config property on non-Rivershare libraries to “Legacy” now (but optionally because the next line defaults to that anyway)?

@JsonProperty("item-agency-resolution-method") private String itemAgencyResolutionMethod="Legacy";

Tim Auger November 6, 2024 at 4:32 AM
Edited

Created this issue to articulate the need to use LocationID to determine an agency. We need to prioritize this for the current sprint. As you know, St. Louis Co. is disabled as a supplier until we can introduce a capability that ensures that a given branch is associated with an agency.

Jag Goraya November 5, 2024 at 9:29 AM
Edited

Fixed

Details

Assignee

Reporter

Effort Estimate

20

Priority

Created November 4, 2024 at 6:30 PM
Updated March 25, 2025 at 4:25 PM
Resolved March 25, 2025 at 4:25 PM

Flag notifications