Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

Questions for module tech leads

...

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 barcode bar code images in templates, but those functions assume that barcode 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? 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? Also, 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?