https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032
--- Comment #10 from Emmi Takkinen <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
