BE | Extend check-out-by-barcode and check-in-by-barcode to accommodate Reading room circulation requests

Description

Overview:

This ticket was generated out of discussions by the working group for Reading Room Circulation. https://folio-org.atlassian.net/wiki/spaces/RA/pages/212303939/RA-Reading+Room+Circulation+Functionality

As a staff member, I require the check-in app to handle items that have a Reading room circulation request on it to be handled differently from other items, both with and without requests.

The main workflow difference is that when an item with an Reading room circulation request in place is checked out, the request is not closed, but instead left open. A normal loan is opened for the patron and the request is moved to "Open - checked out to patron" https://folio-org.atlassian.net/browse/UXPROD-5035 . Upon return the request will either remain open (moved back to "Open - awaiting pickup") or closed based on input form the staff member. Requests will be identified by a flag as specified in https://folio-org.atlassian.net/browse/UXPROD-5037%7Chttps://folio-org.atlassian.net/browse/UXPROD-5037%7Csmart-link%5D.

When checking out an item multiple times to the same user, for the same request i require a way to identify what loan records are for the same user / request combination. This is needed for internal library reporting as to not skew usage reports or to track for how long a item may have been used.

In scope:

Extend the check-out-by-barcode endpoint

  • If a item has an active request that is flagged as being a Reading room circulation request and being charged out to the requestor:

    • The request is not closed

    • The request is moved to the status of “Open - checked out to patron”; JIRA:UXPROD-5035

    • The hold shelf expiration date is retained

    • A loan record is generated based on the current circulation rules

    • All notices, fee/fine polices, etc are unchanged from established workflows

    • The request UUID is added to the loan object

  • All other item / patron / request combinations follow the currently established workflows

Extend the check-in-by-barcode endpoint

  • If the item has an active request that is flagged as being a Reading room circulation request and being checked in by the requestor:

    • Two separate workflows must be accommodated based on a variable passed from he front end; “Close request & return item” and “Keep on hold shelf” (below)

  • All other item / patron / request combinations follow the established workflows.

Workflows check-in-by-barcode

  • Keep on hold shelf

    • The request is moved to the status of “Open - awaiting pickup”

    • The current hold shelf expiration date is retained (is not changed/recalculated)

    • Notices; “Item available for pick” notice is not generated and or sent to the patron (Emails are suppressed)

    • The active loan is closed

      • Any fee/fines are calculated based on established workflows

      • The loan is a standard loan item

  • Close request & return item

    • The request is moved to “Closed - filled”

      • The request is closed and the item is returned to the collection

    • The active loan is closed

      • All established workflows remain intact

    • The item is routed if required

    • New hold slips are printed for the next request in the queue

Permissions:

No extra permissions are needed to check-in or check-out items.

Notes:

This backend ticket covers

  • extend check-in-by-barcode

    • Ticket suppress availability notifications

  • extend check-out-by-barcode


  • Ticket Extend the loan object to hold the requests UUID (mod-circulation-storage - see Jira ticket-XXX)

  • Ticket extend the loan API to expose the request UUID and handle if there is no id present (mod-circulation - see Jira ticket-XXX - to be done before CIRC-2308)

Frontend:

Environment

None

Potential Workaround

None

Attachments

1
  • 19 Mar 2025, 03:09 PM

Confluence content

Checklist

hide

Activity

Show:

Details

Assignee

Reporter

Priority

Development Team

Klemming

Release

Trillium (R2 2025)

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created last week
Updated last week
TestRail: Cases
TestRail: Runs

Flag notifications