In Tools > Batch item modification, one can modify or delete a subfield. When deleting a subfield et modifying another, the wrong subfield gets modified.
Needs Bug 18706 and Bug 18707 to be tested.
Created attachment 63879 [details] [review] Bug 18710 - Wrong subfield modified in batch item modification In Tools > Batch item modification, one can modify or delete a subfield. When deleting a subfield et modifying another, the wrong subfield gets modified. This is caused by the fact that disabled inputs are not posted in form. So for a subfield to delete : Input name=field_value is not posted. But input name=subfield is posted with subfield code. So these 2 arrays does not have the same size : my @subfields = $input->multi_param('subfield'); my @values = $input->multi_param('field_value'); For exemple, deleting $2, not changing $u and modidying $v will modify $u with value for $v o_O This patch correts but setting disabled all inputs of a deleted subfield : field_value, tag, subfield and mandatory. Like it was not present in the form. Test plan : - Go to Tools > Batch item modification - Enter a barcode and submit - Lets say there are subfields : $2 (not mandatory), $u and $v - Check the subfield $2 to be deleted => $2 input is disabled - Enter a text in $v - Submit the form => Without patch, the text for $v gets into $u => With patch, the text for $v gets into $v - Check the subfield $2 is well deleted
This bug also appears with no background job Bug 17240. We use this for nginx + plack
Created attachment 63880 [details] [review] Bug 18710 - batchMod-edit.tt is missing form end tag
(In reply to Fridolin SOMERS from comment #4) > Created attachment 63880 [details] [review] [review] > Bug 18710 - batchMod-edit.tt is missing form end tag Patch application of attachment 63880 [details] [review] fails under both 'git --apply' and 'git bz apply' at line 274.
(In reply to Lee Jamison from comment #5) > (In reply to Fridolin SOMERS from comment #4) > > Created attachment 63880 [details] [review] [review] [review] > > Bug 18710 - batchMod-edit.tt is missing form end tag > > Patch application of attachment 63880 [details] [review] [review] fails under both > 'git --apply' and 'git bz apply' at line 274. The patches applies cleanly on top of bug 18706 and bug 18707 for me...
But I am not able to reproduce this issue...
Yes, I apologize...it was my test box acting funny. The patches do apply. However, prior to applying the patches I also couldn't reproduce the issue either.
The issue is quite hard to explain/reproduce, I'll try to do my best following: - the issue is: if you check the field which makes appear "This subfield will be deleted", all following fields will be shifted upside when you'll submit the form BUT - sometime it doesn't appear if hidden fields are located up to the targeted field, so please check in the source code that no hidden field is present. - the dataTable at the end of the batch modification suffers from another bug: is isn't refreshed with new modifications, to see them, you have to try a new modification, check in the database or on the items interface. However if your modification are all done correctly while a checkbox is checked, this is weird, this is quite weird and I invite you to post the whole precise testplan you followed.
Unfortunately still unable to replicate the problem without a concrete, repeatable test case.
Was able to test during KohaCon 17 with Lauren of SIL and Paul Poulain as the mentor.
Paul, can you share your test plan? I tried 1 - Find a patron with city, state, and zip defined 2 - Select patron for batch modification 3 - Set city = "NEWCITY" STATE-checked to delete ZIP="NEWZIP" 4 - Modification succeeds as expected
(In reply to Nick Clemens from comment #12) > Paul, can you share your test plan? > > I tried > 1 - Find a patron with city, state, and zip defined > 2 - Select patron for batch modification > 3 - Set city = "NEWCITY" STATE-checked to delete ZIP="NEWZIP" > 4 - Modification succeeds as expected I haven't been able to reproduce the bug myself so I'd love to know Paul's test plan as well. Though I believe I'm reading it correctly that the bug occurs in batch item modification instead of batch patron modification :)
Paul, can you share your test plan? I tried 1 - Find an item with copynumber,URI, replacementprice defined (subs t,u,v) 2 - Select item fro modification 3 - Set copynumber = "NEWCOP" URI-checked to delete replacementprice="32" 4 - Modification succeeds as expected
Created attachment 93145 [details] [review] Bug 18710 - Wrong subfield modified in batch item modification In Tools > Batch item modification, one can modify or delete a subfield. When deleting a subfield et modifying another, the wrong subfield gets modified. This is caused by the fact that disabled inputs are not posted in form. So for a subfield to delete : Input name=field_value is not posted. But input name=subfield is posted with subfield code. So these 2 arrays does not have the same size : my @subfields = $input->multi_param('subfield'); my @values = $input->multi_param('field_value'); For exemple, deleting $2, not changing $u and modidying $v will modify $u with value for $v o_O This patch correts but setting disabled all inputs of a deleted subfield : field_value, tag, subfield and mandatory. Like it was not present in the form. Test plan : - Go to Tools > Batch item modification - Enter a barcode and submit - Lets say there are subfields : $2 (not mandatory), $u and $v - Check the subfield $2 to be deleted => $2 input is disabled - Enter a text in $v - Submit the form => Without patch, the text for $v gets into $u => With patch, the text for $v gets into $v - Check the subfield $2 is well deleted Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
I was able to recreate with settings in batch mod: Not for loan - checked to delete Collection code - REF (Reference) Permanent location - LPL (Liberty) Before the patch the value for permanent location ended up in ccode field Disabling the field removes the input and causes off by 1 errors - removing all the fields seems to fix this
Created attachment 93179 [details] [review] Bug 18710 - Wrong subfield modified in batch item modification In Tools > Batch item modification, one can modify or delete a subfield. When deleting a subfield et modifying another, the wrong subfield gets modified. This is caused by the fact that disabled inputs are not posted in form. So for a subfield to delete : Input name=field_value is not posted. But input name=subfield is posted with subfield code. So these 2 arrays does not have the same size : my @subfields = $input->multi_param('subfield'); my @values = $input->multi_param('field_value'); For exemple, deleting $2, not changing $u and modidying $v will modify $u with value for $v o_O This patch correts but setting disabled all inputs of a deleted subfield : field_value, tag, subfield and mandatory. Like it was not present in the form. Test plan : - Go to Tools > Batch item modification - Enter a barcode and submit - Lets say there are subfields : $2 (not mandatory), $u and $v - Check the subfield $2 to be deleted => $2 input is disabled - Enter a text in $v - Submit the form => Without patch, the text for $v gets into $u => With patch, the text for $v gets into $v - Check the subfield $2 is well deleted Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Nice work! Pushed to master for 19.11.00
*** Bug 23715 has been marked as a duplicate of this bug. ***
Please push this to stable and old stable. I consider this a critical bug that can do damage in mass.
Pushed to 19.05.x for 19.05.05
(In reply to Fridolin SOMERS from comment #21) > Pushed to 19.05.x for 19.05.05 +1
backported to 18.11.x for 18.11.11