Versions Compared

Key

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

Date

...

TimeItemWhoDescriptionGoals
5minHousekeeping Andrea Loigman
10minBlocksHolly MistlebauerForgot to ask these two questions when discussing blocks on September 30

1) Should patron notices be sent for manual patron blocks?  Automated patron blocks?

2) Patty W. (a PO) recently asked me about these types of blocks:

  • Informational block where nothing is blocked, you just want the patron's attention -- would this be a note or something else?
  • A way to block the patron from checking out laptops due to their bad past behavior with laptops.
15minClaims returnedEmma BoettcherUser record notes for claims returnedGather requirements for ending claims process and adding note about claim returned to user record. Decide how many notes fields are needed.
30minRequestsCate Boerema (Deactivated)Delivery requests: checking in should automatically check out item to requester

For delivery requests, we had a requirement that said that, when the item was checked in, it should be automatically checked out to the requester (when top request in queue is delivery request). The challenge we have run into is that check out can/should be prevented for a variety of reasons:

  • Check out notes (this isn't a "hard prevent" but could cause staff to decide not to check the item out)
  • Patron borrowing block
  • Loan policy with Loanable = N
  • Patron expired
  • Other?

Given this, we really can't auto-check out items.  Instead, we may need to do the following:

  1. When item is checked in, notify that it is needed for delivery and print delivery slip
  2. Direct user to check out app where requester and item are pre-populated
  3. Happy path: item is checked out and routed for delivery
  4. If checkout doesn't happen for any of the above reasons:
    1. Item in "Awaiting delivery" status
    2. Request in "Open - Awaiting delivery" status
  5. Staff investigates checkout failure and resolves by:
    1. Removing patron block and checking out to requester
    2. Cancelling request and scanning into check in app
    3. Other?

Introducing the new request and item state make this feature significantly more complex.  Do people have ideas for how to simplify for MVP?

If we do decide to introduce the new states, we need to:

  • Update request whitelist
  • Decide whether items that are "Awaiting delivery" can be marked Missing, Lost etc
  • Decide whether requests that are "Open - Awaiting delivery" can expire 
  • Other?


Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

Fees/finesHolly MistlebauerPost-MVP

Holly created 2 JIRA issues:

UXPROD-2109: Allow for patron notices to be sent on request for manual patron blocks

UXPROD-2108: Expand patron blocks to allow blocking of borrowing by material/item type


Informational blocks will be handled by user notes
LoansEmma BoettcherQ4

Add additional field for patron-facing (notice) information in declared lost & claim returned resolution actions

When resolving a claim returned item, create a note on the user record with the outcome of the claim and a link to the loan.


RequestsQ4

Above described solution with new item and request state seemed like best approach to SIG.

We updated the request whitelist

And we specified some other key requirements in this document: https://docs.google.com/document/d/1iWhEAxd3hvlvqmDgXmbJ2a3A_J2ahQHaMN2RKvDLvWI/edit?usp=sharing

I have enough to go on for now.  May come back with follow up questions later.



Notes

  • Blocks - Holly Mistlebauer

...