[Koha-bugs] [Bug 15876] New: Removing a course-reserved item with no initial shelving location does not revert items.location to NULL

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

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

            Bug ID: 15876
           Summary: Removing a course-reserved item with no initial
                    shelving location does not revert items.location to
                    NULL
 Change sponsored?: ---
           Product: Koha
           Version: 3.20
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Course reserves
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: theod at lib.auth.gr
        QA Contact: testopia at bugs.koha-community.org

(This happens only when one changes the shelving location while the item is on
a course_reserve)

Steps to replicate:

1) Find an item with NO shelving location info (ie one that has
items.location=items.permanent_location=NULL in the DB and the OPAC/Intranet
shows an empty string)
2) Add this item to a course reserve
3) Either when adding the item in the course reserve, or at a later stage
CHANGE (from the course reserve screen!) the 'temporary' shelving location info
that will be used by that course reserve, by selecting a value from the
drop-down list. Let's say 'On Display'
4) Find the item in the OPAC or Intranet, the change is displayed (as expected)
5) REMOVE this specific item from the course reserve
6) Find the item again in the OPAC or Intranet. All the course-reserve related
information is reverted back to the original values as expected, except the
shelving location, which is NOT reverted back to 'empty'. The old value (in our
example 'On Display') is still shown!.

FYI, NULL is added from items.location to course_items.location in step 2 as
expected
However, that NULL value in NOT copied back to items.location or
items.permanent_location in step 5 as expected, but instead the value from step
3 is retained.

(I have verified this behavior both with 3.20 and 3.22)

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