https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032
--- Comment #9 from Katrin Fischer <[email protected]> --- (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? -- 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/
