http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8735
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |[email protected] --- Comment #20 from David Cook <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
