Bug 27637 - Allow ReservesMaxPickUpDelay to be adjusted based on item values
Summary: Allow ReservesMaxPickUpDelay to be adjusted based on item values
Status: RESOLVED DUPLICATE of bug 19309
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-05 13:07 UTC by Andrew Fuerste-Henry
Modified: 2021-02-08 12:55 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2021-02-05 13:07:13 UTC
The syspref ReservesMaxPickUpDelay contains a number of days to be added to the current date in order to derive the expiration date for a hold. It allows no variation for item types, libraries, etc.

I propose a new companion syspref of ReservesMaxPickUpDelayAdjustments (or something). It'd take a set of item table fields, values, and numbers to be added to the ReservesMaxPickUpDelay value. So something like:
holdingbranch: CPL: 2
itype: DVD: -3

Would mean holds on items at CPL would get 2 extra days, holds on DVDs would get 3 fewer days.
Whatever syntax we arrive at should allow grouping conditions, so a library could adjust pickup delays for only a specific itype at a specific branch, for example.
Comment 1 Katrin Fischer 2021-02-06 20:21:28 UTC
Hi Andrew,
there is an older bug about moving this to the circulation conditions:
Bug 19309 - Add ReservesMaxPickUpDelay to the Circulation Matrix 

What do you think of that proposal vs the system preference?
Comment 2 Andrew Fuerste-Henry 2021-02-08 12:53:54 UTC

*** This bug has been marked as a duplicate of bug 19309 ***
Comment 3 Andrew Fuerste-Henry 2021-02-08 12:55:16 UTC
Handling this as a circ rule makes sense. I was thinking of something that would be a bit more flexible, but in practice I suspect folks would mostly want to tie this to patron category and itemtype.