https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032 --- Comment #10 from Emmi Takkinen <emmi.takkinen@koha-suomi.fi> --- (In reply to Katrin Fischer from comment #9)
(In reply to Emmi Takkinen from comment #8)
(In reply to Marcel de Rooy from comment #5)
$hold->set( { priority => 1, found => undef, waitingdate => undef, expirationdate => $hold->patron_expiration_date, itemnumber => $hold->item_level_hold ? $hold->itemnumber : undef, } )->store({ hold_reverted => 1 });
Currently, only this case triggers part of the condition (that could be simplified to reduce repetition) that leads to calling: $self->_set_default_expirationdate; (Unless both dates are still the same..)
If they are not, why not respect patron_expiration_date?
Because I just realized there is a column called patron_expiration_date. Somehow this has totally slipped from my attention. You're right, if patron_expiration_date exists we should respect it, not generate new one. However, what should we do if patron_expiration_date is in past?
It's a really good question. My thought would be to use the existing date anyway, even if in the past. Some libraries might not auto-cancel those and if they auto-cancel that will be run nightly, so there is still a moment to adjust. Maybe we could do an alert or other visual hint?
Hmm, maybe displaying field as red would be enough? -- You are receiving this mail because: You are watching all bug changes.