[Bug 16201] New: Tie automatic cancellation of holds to a system preference to allow easier configuration
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16201 Bug ID: 16201 Summary: Tie automatic cancellation of holds to a system preference to allow easier configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: katrin.fischer@bsz-bw.de QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Currently, if you run multiple instances on a server, you can not easily configure for some, but not others, that holds not picked up will automatically cancelled. The cronjob used is: misc/cronjobs/holds/cancel_expired_holds.pl If it's scheduled, the feature is active for all instances - or you'd have to maintain a list, change the default cron files etc. It would be nice if this feature was tied to a new system preference, so that you can easily activate/deactivate it from within Koha and without accessing the server. This might also be useful for libraries that want to wait a little longer with cancelling in some cases, for example after a holiday period or when the library has been closed for a while. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16201 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Tie automatic cancellation |Tie automatic cancellation |of holds to a system |of expired holds to a |preference to allow easier |system preference |configuration | --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- This would still be nice to have :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16201 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m --- Comment #2 from Lisette Scheer <lisette@bywatersolutions.com> --- Doesn't ExpireReservesMaxPickUpDelay do this? Or does that not matter if the cron is running? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16201 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Tie automatic cancellation |Tie automatic cancellation |of expired holds to a |of expired non-waiting |system preference |holds to a system | |preference --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Lisette, thanks for looking into this! I had to dig a little deeper to figure out what I was thinking about here in 2016: The ExpireReservesMaxPickUpDelay seems to only be used for waiting holds, but it will still expire other "expired" holds that are not waiting yet, if I read the code correctly. sub CancelExpiredReserves { my $cancellation_reason = shift; my $today = dt_from_string(); my $cancel_on_holidays = C4::Context->preference('ExpireReservesOnHolidays'); my $expireWaiting = C4::Context->preference('ExpireReservesMaxPickUpDelay'); my $dtf = Koha::Database->new->schema->storage->datetime_parser; my $params = { -or => [ { expirationdate => { '<', $dtf->format_date($today) } }, { patron_expiration_date => { '<' => $dtf->format_date($today) } } ] }; $params->{found} = [ { '!=', 'W' }, undef ] unless $expireWaiting; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org