Bug 21638 - Allow reporting of holds cancelled by cancel_expired_holds.pl and ExpireReservesMaxPickUpDelay
Summary: Allow reporting of holds cancelled by cancel_expired_holds.pl and ExpireReser...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 18.05
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-23 21:04 UTC by Andrew Fuerste-Henry
Modified: 2023-04-03 16:17 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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2018-10-23 21:04:41 UTC
When ExpireReservesMaxPickUpDelay is set to Allow, waiting holds are automatically cancelled by cancel_expired_holds.pl. But, generally, libraries still need to physically remove those items from their hold shelf and check them in to guarantee there are not pending holds or transfers to be triggered. A report to identify these items is imperfect and cannot definitively distinguish a hold cancelled by the cron from a hold cancelled by an employee.

Bug 14134 established behavior that displays holds which *will* be cancelled by the next run of the cron on the "holds over" tab in Holds Awaiting Pickup, but doesn't allow staff to see which holds have already been cancelled.

It'd be great if the cron could email a list of cancelled holds.
Additionally, reporting would be improved by the introduction of a new value in old_reserves.found for items cancelled by the cron (maybe E for expired).