[Koha-bugs] [Bug 34032] Holds expirationdate left blank if waiting status is reverted

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34032

--- Comment #10 from Emmi Takkinen <emmi.takkinen at 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.