Versions Compared

Old Version 3

changes.mady.by.user Cate Boerema (Deactivated)

Saved on

compared with

New Version 4

changes.mady.by.user Cate Boerema (Deactivated)

Saved on

Key

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

Date

...

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
Misc

Cate Boerema (Deactivated)

TBD
  • We will want to be able to prevent checkout and requesting of electronic items
  • Can create an "electronic resources" loan policy which is loanable = N and associate it with the electronic location(s) though circ rules
  • Can create an "electronic resources" request policy which disallows all requests and associate it with the electronic location(s) through circ rules
  • In discovery, you will probably not want the item status "Available" to display, as the resource may not be available.  Might need another item status for these resources to make it simpler for discovery to display the correct status.  It would be technically possible  to do this without a dedicated status, but less efficient to code discovery to display something special when Item status = Available AND Item location = Electronic.  Could be an argument for getting started on custom statuses.  NEED TO DISCUSS FURTHER WHEN WE HAVE REPRESENTATIVES OF INSTITUTIONS THAT PLAN TO USE ITEMS FOR E-RESOURCES.






Request Statistics (for Performance Testing)

...

  • requests on loan details screen - do we want to display all requests or only those that impact due date?

    • yes we want all of the requests to show up as an action

    • also confirming that count of requests on item record takes you to list of all requests on item

  • clearing the hold shelf - cancelled and expired requests

    • original idea for expired was for request status and item status awaiting pickup by filtering

    • how do you come up with the complicated query logic for finding expired holds that need to be grabbed? logic is complicated by outstanding open requests

    • a new item status of "pickup expired" that is updated when request is expired or cancelled would simplify the discovery of these items

    • item status of "pickup expired" and necessary request info (patron name, barcode)

    • obviously need to limit by service point

    • report needs requestor, item barcode, title, item call number

    • assumption is that item state, etc. should be configurable at discovery layer level for display

  • Hold shelf expiry period can be specified in minutes and hours, is this needed? 

    • the challenge is that the batch process or other query, how often does it need to happen?

  • Request Expiration Job

    • current implementation is that the system checks every hour, not a batch job (right now)

    • probably do need minutes/hours for reserves, equipment, etc.

    • need to do performance testing - estimates on average numbers posted as table, please contribute your institutions estimates

    • Chicago - 20-25% of requests expire or are cancelled

How many newly expired requests might there be per day