[Koha-bugs] [Bug 8735] Expire holds waiting only on days the library is open

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8735

David Cook <dcook at prosentient.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |Patch doesn't apply
                 CC|                            |dcook at prosentient.com.au

--- Comment #20 from David Cook <dcook at prosentient.com.au> ---
Hey Kyle, I couldn't get the patch to apply on the latest master.

Applying: Bug 8735 - Expire holds waiting only on days the library is open
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Auto-merging installer/data/mysql/sysprefs.sql
CONFLICT (content): Merge conflict in installer/data/mysql/sysprefs.sql
Failed to merge in the changes.

As for the actual bug, I'm not sure that I could reproduce it. Before applying
the patch, I used your test plan to the letter (expecting for my hold to
disappear on a holiday), but when I set my "waiting date" to yesterday and ran
"misc/cronjobs/holds/cancel_expired_holds.pl", it didn't clear out the reserve
(regardless of the day being a holiday). If I set it for the day before
yesterday (both as a holiday and not), I got:

DBD::mysql::st execute failed: Duplicate entry '60' for key 'PRIMARY' at
dev/lib//C4/Reserves.pm line 1051.

It cleared out the entry from the reserves table, but that doesn't seem very
elegant. Is that how it's supposed to look?

--

I guess what I'm asking is...could your test plan include a "Before patch" and
an "After patch" so that I can see what buggy behaviour is being fixed?

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