http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8735 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |dcook@prosentient.com.au --- Comment #20 from David Cook <dcook@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.