Bug 23715 - Batch item modification sets a value in incorrect field
Summary: Batch item modification sets a value in incorrect field
Status: RESOLVED DUPLICATE of bug 18710
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: 18.11
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-01 18:23 UTC by Christopher Brannon
Modified: 2019-10-02 15:27 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2019-10-01 18:23:23 UTC
We have a scenario, in which we are removing a damaged status from a batch of items and setting a not for loan status.  When we check to delete the Damaged status (which in this case has a value of 4), and set the Not for loan status (in this case, a status with the authorized value of -3), it deletes the Damaged status, but instead of setting the status of the Not for loan field, it assigns the authorized value of the Not for loan status to the Use restrictions field.  So, all the items do not get the Not for loan status, and all the items show a -3 in the Use restrictions field.
Comment 1 Christopher Brannon 2019-10-01 18:36:13 UTC
Please be aware that this issue happens when you are doing these things together.  Changing the status of one field seems to work fine, but when doing them together, you get this result.
Comment 2 Katrin Fischer 2019-10-02 06:33:58 UTC
Hi Christopher, we just fixed a bug like this (waiting for Rmaints currently): bug 18710. Marking duplicate, please check and change back if I am mistaken!

*** This bug has been marked as a duplicate of bug 18710 ***
Comment 3 Christopher Brannon 2019-10-02 15:27:42 UTC
(In reply to Katrin Fischer from comment #2)
> Hi Christopher, we just fixed a bug like this (waiting for Rmaints
> currently): bug 18710. Marking duplicate, please check and change back if I
> am mistaken!
> 
> *** This bug has been marked as a duplicate of bug 18710 ***

Yep, that's the culprit.  Hope they will backport it.  I consider it critical since it will do unwanted things to mass records.