[Koha-bugs] [Bug 19260] Reservations / holds marked as problems being seen as expired ones and deleted wrongly.

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

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

Josef Moravec <josef.moravec at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |ASSIGNED
                 CC|                            |josef.moravec at gmail.com

--- Comment #6 from Josef Moravec <josef.moravec at gmail.com> ---
(In reply to Magnus Enger from comment #2)
> Created attachment 67428 [details] [review]
> Bug 19260 - Restore ExpireReservesMaxPickupDelay
> 
> It looks like bug 12063 accidentally removed the functionality of
> ExpireReservesMaxPickupDelay. This patch aims to restore it.
> 
> To test:
> 
> Before applying the patch:
> - Make sure ExpireReservesMaxPickUpDelay = "Don't allow"
> - Check out a book to a user
> - Add a reservastion on it for another user
> - Check the hold in the database. You should have:
>   found = W, waitingdate = today, expirationdate = today + the value of
>   ReservesMaxPickUpDelay
> 
> The problem here is the expirationdate, it should be empty when
> ExpireReservesMaxPickUpDelay = "Don't allow".
> 
> After applying the patch:
> - Repeat the steps above
> - expirationdate should now be NULL
> 
> Please be creative when testing this. I am not sure I have seen
> all the possible concequences.

I don't think, that is the right place to fix it... after 12063, we really need
a date in expirationdate I think...

ExpireReservesMaxPickUpDelay just has to say, if cancel also waiting reserves
or not...

Attachment 63095 Bug 12063 - Fix QA failures

added this to C4::Reserves.pm

+ sub CancelExpiredReserves {
+     return unless C4::Context->preference("ExpireReservesMaxPickUpDelay");

After this Marcel's comment:

 sub CancelExpiredReserves {
+    return unless C4::Context->preference("ExpireReservesMaxPickUpDelay");
This may have a unwanted side-effect. If we do not use the pickup delay, but
still want to cancel expired reserves. It is no longer possible. (Note that
patrons may have entered expiration dates too.)
Not marking this as a blocker, since this is probably exceptional. Do you have
an easy fix or can you open a new report for it?

The return line was removed...

The comment is right, when ExpireReservesMaxPickUpDelay is false, then no
reserve is canceled - even that which should be (not waiting bud after
expiration date)

But the solution should be more complex (and yes, we will need tests for this)

The CancelExpiredReserved has to deal with ExpireReservesMaxPickUpDelay - nad
use the different SQL for this two cases.

-- 
You are receiving this mail because:
You are watching all bug changes.