Bug ID: 19974
Summary: Marking an item as 'lost' will not actually modify the
current item (cataloguing/additem.pl)
Change sponsored?: ---
Priority: P5 - low
Assignee: [hidden email] Reporter: [hidden email] QA Contact: [hidden email] CC: [hidden email]
When modifying an item through the intranet at the page
/cgi-bin/koha/cataloguing/additem.pl?op=edititem, instead of changing the
active item's information, the markaslost parameter will be applied to the
first Item in the database that has no itemnumber.
I'll submit a patch soon with a clear test plan. This should fortunately not
take too long to test.
1) Log in with your superlibrarian account
2) Borrow any book
3) Visit your Checkouts page, and click 'Show Checkouts'
4) Click on the item's barcode to visit the item's page
5) On the item's page, click the 'Edit' button, and choose 'Edit items'
6) In the items table, click the 'Actions->Edit' button of the item you
7) Mark that item as lost (it should be the first row of the form) and
click the button 'Save changes'
8) Visit your Checkouts page. The item should still be there, despite
BZ12363 claiming it should've been automagically returned
8.1) Your koha-log should also output a warning message:
'DBIx::Class::Storage::DBI::select_single(): Query returned more than one
8.2) If you visit the item's page, the modification had no effect. It
should not be marked as lost.
9) APPLY PATCH
10) Start back from step 2), but this time, after marking the item as lost,
the item's page should
reflect the change, and the item you borrowed should've been
automatically returned to the library
--- Comment #2 from Charles Farmer <[hidden email]> ---
To my knowledge, emptying $itemnumber is only done so we don't fall back onto
the same item after saving changes. On one hand, we load back into the
$op=additem interface if changes were accepted, otherwise, we load the same
What's lost on me is the reason why we'd want to proceed with the deletion
logic at all if the newitem has a barcode already used. Is there code anywhere
edging on that voodoo logic of deleting an item from an unsaved biblionotice?
What would make sense, imo, is pushing that deletion logic upward inside the
'else' block and doing that at the same time as ModItemFromMarc. But again,
without a strong regression test suite of that particular part, I went with the
easy way out and changed as little as I could with my patch, behavior-wise.
--- Comment #3 from Charles Farmer <[hidden email]> ---
I made a mistake describing what happens at point 8.2 of the test plan: the
item _will_ surely be marked as lost, make no mistake about that. If you filled
information inside additem.pl's form, it will definitely have an impact on the
item you were editing (i.e. you _should_ see the item marked as lost in your
account and on the item's page).
What's missing from BZ12363 is the _LostItem_ logic that should happen right
after an item is newly marked as lost.
What |Removed |Added
Status|Needs Signoff |Signed Off
--- Comment #4 from jmbroust <[hidden email]> ---
Signed off on sandbox 8. I had an error message from the sandbox when I signed
"It seems you don't have applied a patch, so you cannot sign it off. If you
applied patches from the right report, check the commit message of the last
patch. It should start with "Bug XXXXX", if not, please inform the author of
I tried to install again and still have a positive message result for the
install : Sandbox setup by [hidden email] with database -1
and bug 19974 on Tue Mar 13 12:06:26 2018