Page tree
Skip to end of metadata
Go to start of metadata



Discussion tems


15minNotice logic - follow-upDarcy Branchini
Approval: to move forward with logic in notice policies
15minRequests: Check in modalsCate Boerema*
Review of mockups and stories related to check-in modals for in transit and awaiting pickup requests:
25minRequests: Paging requestsCate BoeremaItem State Use Cases- reviewApproval of paging use cases

Meeting Outcomes

Functional Area

Product Owner

Decision Reached


Link to Supporting Materials


e.g. loans, fees/finesNameClearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue
RequestsCate Boerema

The information in the Awaiting pickup modal attached to UICHKIN-50 - Getting issue details... STATUS is correct

UICHKIN-50 - Getting issue details... STATUS

  • Next step on modal is to get a good UX mockup so we are sure we are using the right patterns etc
  • It was suggested that hold slips should have the option to display pickup service point (in case the item is discovered somewhere random, you would like to know where it should be sitting) - Darcy Branchini will create story for adding a token for pickup service point to the hold slip
  • It was requested that you be able to specify for each service point whether hold slips will print by default and whether transit slips will print by default - Cate Boerema will have this mocked up and bring to SIG
RequestsCate Boerema

The information in the In transit modal attached to UICHKIN-49 - Getting issue details... STATUS is correct

UICHKIN-49 - Getting issue details... STATUS

  • Next step on modal is to get a good UX mockup so we are sure we are using the right patterns etc
RequestsNeed to be able to configure which request types are allowed for which item states (availability)
  • For example, some institutions may allow hold requests on On Order items while others don't
  • When there are custom availability states, you will definitely need this
  • Most systems today allow this

  • Cate Boerema will discuss with developers
  • Update 2018-10-23: Discussed with Jakub. He suggests we go ahead with hard-coded rules (if necessary) and make this configurable later once we have a bigger picture understanding of the various request rules and policies and where they live. He didn't think this result would result in a lot of throw-away work ("it's relatively easy to replace hard-coded values if you know where the data comes from")
RequestsWe can assume that Recall requests are only allowed when Availability = Checked out


Notice logic - follow-up (Darcy)

  • Darcy framed the conversation by noting that there were currently two different approaches to considering how to configure patron notices:
    • 1) To consolidate patron notice types together into bundled notice policies (e.g., fee/fine, overdue, etc. consolidated into notice policy A, which covers both)
    • 2) To split them out into separate notice policies (e.g., fee/fine notice policies separate from overdue notice policies) and call each separately through the circulation rules editor
  • She walked the group through a spreadsheet (LINK) containing some use-cases for the consolidation approach.  The spreadsheet contained columns for Template|Event Trigger|Notes|Caveats/Gotchas
    • She also noted that the Fee/fine tab contained alternate scenarios (e.g., fee/fine notices triggered by periodic scan)
  • David noted that, in his case, he didn't want to have to repeat the effort to encode the same recall notice logic into each individual 'bundled' policy (e.g., I might have many loan policy types, but only one fee/fine notice policy that would apply to all).  Darcy noted that this might be able to be accomplished in the Circulation Rules Editor by having a single 'fall-back' policy defined that would apply to all encoded circulation rules without having to duplicate effort.
  • Andrea...

<Sean - I need to review the recording again to complete the notes>

Requests - Check-in modals for in-transit requests (UICHKIN-49) (Cate)

  • Cate presented the modal and noted that it still needed a UX review to ensure it's using the appropriate conventions.
  • She also noted that the routing indicated on the modal needed to be for the Service Point name, not the library name
  • The group approved the mock-up

Requests - Check-in modal for item that is awaiting pickup (UICHKIN-50) (Cate)

  • Cate presented the modal and noted that it still needed a UX review to ensure it's using the appropriate conventions.
  • The group approved the information displayed in the modal
  • The group noted that they would like the default (print=Y or print=N) to be configurable for:
    • 1) Different types of slips (i.e., hold, transit) AND
    • 2) Different service points
    • And noted that the ability to override the default from within the modal should be allowed
  • The group agreed that these would be appropriate to configure in the service point record
    • Hold slip printing (default=Y|N)
    • Transfer slip printing (default=Y|N)
  • Cate will mock these additions up and bring back to the group to review

Requests - Paging Requests (Cate)

  • Asked whether there were formatting options for the slips themselves, Cate noted that there were different tokens to choose from to display on the slips.  Request from the group to add 'Pick-up service point' as an optional token to display on Hold Slips (FOLIO>Settings>Circulation>Staff slips>Hold.  Darcy agreed to add a story for this.
  • Cate continued with the review of Tania's Item States - Use Cases spreadsheet, and reviewed the use-case for 'Paging request - Can be filled at pickup location' (Line 15 in the current spreadsheet).
    • Asked whether 'available' was the only starting item state allowable for paging requests
      • Group noted that you probably want to be able to define these separately, rather than hard-code them into the application
        • An example - In addition to 'Available', 'Recently returned' might be another starting item state that would be allowable for paging requests at a particular institution
      • Asked whether we could limit the initial implementation to those that have already been defined and add custom configuration later
        • David pressed on the need for customization - e.g., In process, on order - what states are these?  Also, you may not know what 'state' an item is in (e.g., items in storage)
      • Cate asked whether this same need would apply to other use-cases in the spreadsheet as well (e.g., Recalls and Holds)
        • Yes
      • Cate will talk to the developers about this to define which states you can create these
    • Asked whether 'available' as the ending item state was okay - the group agreed.
    • Asked whether 'requests' and 'checkouts' were the only states allowable 'In the new state'
      • David - again, customization is needed - e.g., what happens to trumped paging requests - do the original requests automatically turn into holds? - will want different configurations.
      • Mark noted that it seemed logical, in this case, for the original page to be cancelled, but agreed that it should be configurable to decide whether to auto-contact the patron.
      • The group noted that they needed to spend some time to think these workflows through.
      • Cate added updates directly to the spreadsheet to reflect the discussion points (G15 in the current spreadsheet)
    • Cate asked whether local request rules had been shared in the requests subgroup.  It was noted that this was challenging as these were stored in different places, but that they could gather these and do a walkthrough in ta future meeting.


  1. I have a question concerning the formatting options of the request/hold slips - At UB Leipzig a lot of requested materials are delivered to a "self-service-area" where the patrons can pick them up and check them out themselves. For privacy reasons/data protection we are only printing the patron´s barcode on the slip, not the name. Would it possible to add the patron barcode besides the other options?

  2. Hi lisa perchermeier!   Thanks for your comment.  I submitted a user story for adding this token:  UICIRC-95 - Getting issue details... STATUS