-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIRC-2136 support floating collections #1505
CIRC-2136 support floating collections #1505
Conversation
…on into deployment
Circ 2136 floating collections
Circ 2141
-- when current process is not a check-in but a page request
Circ 2136 floating collections
…into CIRC-2136-floating-collections
Circ 2136 floating collections
CIRC-2136 set new location on check-in response and pick slip context.
Hi @kurtnordstrom , I think Vega could be bogged down by PRs and releases for Ramsons at this stage. Could you maybe review this PR? It's been tested in https://linkoping.folio-dev.indexdata.com/ by our sponsor (Linköping Universitet) for quite some time now and the implementation has been approved by them. |
…into CIRC-2136-floating-collections
Quality Gate passedIssues Measures |
Purpose
A floating collection is a group of items that are not housed permanently at a specific library, but belong to whichever library has most recently checked in the the item. Using a floating collection will reduce transit time or shipping expenses if sites do not want to move these materials between libraries.
Approach
A floating collection is to be defined at the location level, by setting a boolean flag on the location: isFloatingCollection. This is a change in mod-inventory-storage, that is already released, see MODINVSTOR-1250.
All processing of the flag happens in mod-circulation. The new logic is an extension to the check-in procedure, CheckInByBarCodeResource, and related helper classes, like CheckInProcessAdapter, LocationRepository, UpdateItem, etc.
In the first part of the existing check-in procedure there is a new call to find a floating collection, if any, at the check-in service point, if the item's current location is floating. This look-up only happens if the item's location has the float flag set. If the item can float (is from a floating collection and is being checked in at a remote service point that serves another floating collection), there is a new interception in the code that will normally be putting the item in transit to the origin service point, but not now if it can float. And then, when the item is about to float instead of being in transit, there is additional logic to change the item's temporary location (and thus its effective location) to the new floating collection.
The float logic will not kick in, if there is a request on the item at another service point. In that case the usual in-transit logic applies.
TODOS and Open Questions
It will be possible to extend this logic to support multiple floating collections per service point, for example different locations for different material types, but there's is no known use cases for such logic at this point, so this solution only supports one floating collection per service point. The storage layer (mod-inventory-storage) does not enforce that, though, and if the admin designates multiple locations served by the same service point as floating collections, then the logic of this PR will simply pick the first floating collection it finds and set that as the item's new temporary location.