http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 18674 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18674&action=edit Bug 10382 - collection not returning to null when removed from course reserves Test Plan: 1) Create an item, do not set a collection code 2) Add the item to a course, and choose to set a collection code 3) Ensure the course is enabled, and the collection code is now visible 4) Disable the course, ensure the collection code is no longer visible -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #3 from Kyle M Hall <kyle.m.hall@gmail.com> --- (In reply to comment #2)

There is a conflict between the bug description and the test plan that leaves me rather confused. The bug report talks about removing an item from course reserves, but the test plan talks about disabling the course while leaving the item in the course reserves. Are item fields supposed to get set back to what they were before being put on reserve if they are removed from course reserves, or is that functionality that has not been implemented?

Yes, disabling all courses an item is attached to and removing an item from all courses it is attached to are functionally equivalent ( as far as the `items` table is concerned ). I wrote the test plan to make it quicker to test. In both cases fields should revert to the original values. Nobody including mysql thought of a scenario where a field would go from not having a value to having a value and back. It was always switching values, or not modifying the field at all. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- I'm afraid I cannot reproduce your issue with this patch. I've tested it using both location and ccode, and checked the revert by 1) Disabling the course the item is part of 2) Deleting the item reserve from the course 3) Deleting the course itself ( and thus all reserves for the course ). Kyle (In reply to comment #4)

Okay, in that case the fix doesn't work for me. I changed ccode to non-fiction when putting the item into course reserves, and when I removed it from course reserves, ccode remained non-fiction.

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- The latest patch corrects this problem:

3) Looking at the entry on the course detail page, the ccode column shows "Unchanged ([my ccode])."

...but not this one:

5) View the detail page for that item: ccode is not null. It's still the ccode I set it to when I added it to the course.

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de Severity|major |critical --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I ran into this during my workshop last week as well - upping severity a bit as it seems to me that this means basic functionality of course reserves is not working correctly. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Kyle, could you take another look at this? I think it's almost a blocker, as your items will not be reset to the correct state if the fields has been empty (which is kind of a data loss) -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 Derryn <derrynj@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |derrynj@gmail.com -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #12 from Kyle M Hall <kyle@bywatersolutions.com> --- If someone would be willing to write some unit tests to demonstrate the issues I'd be more than happy to continue work on this bug. I think the issue is triggered by removing an item from course reserve, and *not* triggered by simply disabling the course reserves. Can someone confirm this? -- You are receiving this mail because: You are watching all bug changes.