DRAFT. Technical solution, reading room circulation.

Introduction

The Epic UXPROD-1835 describes the defined work for Reading Room Circulation Functionality.

The purpose of this feature is to create a modified workflow that enables patrons to use certain items within the library. These items are typically stored in closed stacks or are restricted in the Integrated Library System (ILS). Patrons can request these items, which are then delivered to a designated staff area for in-house use (reading room circulation functionality).

Other purposed workflows include special collections, and in-house use only Inter-library Loan items.

Work on Spike / POC is captured in: UXPROD-5095

Requirements

• Allow patrons to place requests at service points, and via discovery layers

• Allow for materials from closed stacks or restricted collections to be delivered to a service point

• Provide all related notices - Canceled, available, expired.

• Allow for the circulation of materials to patrons

  • During check-out, the request is retained on the item; the request is moved to “Open - checked out to patron”

  • upon check-in, staff are allowed to choose if the item should be returned to the stacks or returned to the hold shelf

• Allow staff members to change a standard request to/from a reading room circulation request

• Provide metrics that can be reported on and searched upon in the UI; Circulation log, Requests app, Lists app, and LPD/MetaDB.

In scope

Work defined by the RA-SIG working group on Reading Room Circulation Functionality. Work developed by the Klemming development team for Sunflower and Trillium will have as primary focus Reading Room Workflow as needed for National Library of Sweden in order to go live Q1 2026.

Open

Not in Scope

• Items without barcodes or items not in FOLIO; New feature request to be worked on later.

• Delivery to areas other than service points.

• Restrict circulation to specific service points; New feature to be worked on later.

Use cases

Proposed solution/technical design

During initial discussions within the RA SIG Working Group on Reading Room Circulation Functionality, it was concluded that expanding the current Requests app and Check-in / Check-out apps would require fewer development resources but also make sense since the Request app already allows for the vast majority of needed workflows.

• Requests policy page

  • Expand Request policies to allow system administrators (staff) to have a request act as a Reading room circulation request. This would set a flag on the requests object to indicate that it is a reading room circulation request. This approach would require no changes to discovery layers as it is not a patron-facing option.

  • Move hold shelf expiration to the Requests policy, and extend it to allow for more complex hold shelf logic.
    Requests app

  • Modify the create / edit requests form to add a new option to indicate that the request is/is not a Reading room circulation request. This interface would be similar to the title level or item level request option. Since this function does not alter the request workflow until check-out no logic is needed.

  • Modify the Requests app main page to allow for the filtering of items that are currently checked out to patrons.
    Requests object

  • Add a flag to the request indicating that it is a Reading room circulation request.

  • Allow staff to set a default value via Request policies (above)

  • Allow staff to change a request to a Reading room circulation request via the new request form or edit request form.

  • Any request marked as a Reading room circulation request will not be cleared until explicitly told to do so my a staff member via check-in, the request is canceled or the request expires.

    • Persistent through check-in / check-out
      Check in/out

  • Check-out.

    • The request is not removed when the item is checked out to the requesting patron

    • The request is moved to “Open - checked out to patron” status.

    • A standard loan record is created and all notices are generated as currently defined in the system.

    • The request UUID is saved to the loan record to assist in reporting.

  • Check-in.

    • The staff member is allowed to select if the item should remain on hold or be returned to the shelves.

      • Service point settings will include a new setting for the default action to take.

      • A drop-down will be added to Check-in to allow users to change the check-in action

      • options:

        • Keep on hold shelf: The request is changed to “Open - awaiting pickup”; notices are not sent.

        • Close request & return item: The request is closed.

        • Ask for action: A modal is displayed asking which of the above two actions should be taken.

    • The loan is closed, all related notices are canceled.
      Supporting needs

  • Add new tokens to Staff slips and to Email

  • Add “Default check-in action for Reading room circulation” to service point settings

  • Add a new settings page for “Request type tokens” (TBD)

  • Expand the staff slip editor to allow for more complex layouts

  • Add a Reading room circulation option to the Request policy form

Open questions

1. For tech lead of mod-template-engine. Reference: UXPROD-5029. One requirement is a new option to add a bar code image for item.instanceHrid in templates. There are already functions generating bar code images in templates, but those functions assume that bar code values are in tokens named something with 'barcode', so some rearrangements in mod-template-engine are likely required to support image generation for values in tokens named differently, like 'item.instanceHrid'.

   1. From UXPROD-5029:

      1. {{item.instanceHrid}} {{item.instanceHridImage}} Instance HRID - A text and barcode representation of the Instance HRID

2. To be understood by the developers. Reference: UXPROD-5029. Any item can be tagged with one or more statistical codes, represented as a list of UUIDs in the item object. The codes would have a label and they would belong to a category (a code type), both of which could be looked up outside of the item itself. There is a requirement to be able to select certain codes as tokens, and if selected by the user they should be represented as boolean values based on whether or not the given codes are present on the item. It is not entirely clear, what criteria should be used in deciding which codes to make available for selection, exactly how the token selector UI would then present these options, and how the true/false value would ultimately be used in the notice/slip template. Mock-ups of the token selector and the template editor with data examples might help. It cannot be ruled out that some refactoring of the template engine would be required to support the logic of this. With clarified requirements, the performance impact could be analyzed. For example: Each such lookup -- be it by category, label or UUID -- would be very cheap, but if its done for many more items or codes than strictly necessary it could have a cumulative impact on the general check-in/check-out procedure, which is already strained by a large numbers of (equally cheap) look-ups.

3. To be investigated. Reference: UXPROD-5037. One requirement is to add a new boolean property with a default of false to the request object to indicate that a request is a reading room request. The ticket lists a task of back-filling existing requests with “false” since no requests are reading room requests so far. Back-filling might not be necessary, though, given that the default is already “false”.

4. Questions regarding the item.

   1. As an item is being picked up by the patron and returned by the patron, the request status will change. What about the item status?

   2. In the earliest design considerations it was suggested that items were statically flagged as being reading room items; it appears that this idea has been abandoned?

   3. What is the role of the statistical codes of code type “Reading room circulation”, that will be tagged on the item?