|Summary:||Wrong subfield modified in batch item modification|
|Product:||Koha||Reporter:||Fridolin SOMERS <fridolin.somers>|
|Component:||Tools||Assignee:||Fridolin SOMERS <fridolin.somers>|
|Status:||Failed QA ---||QA Contact:||Testopia <testopia>|
|Priority:||P5 - low||CC:||baptiste.wojtkowski, caballeromaricon, josef.moravec, ldjamison, nick|
|Change sponsored?:||---||Patch complexity:||Small patch|
|Bot Control:||---||When did the bot last check this:|
|Who signed the patch off:||Text to go in the release notes:|
|Bug Depends on:||18707, 18706|
Bug 18710 - Wrong subfield modified in batch item modification
Bug 18710 - batchMod-edit.tt is missing form end tag
Description Fridolin SOMERS 2017-05-31 14:43:57 UTC
In Tools > Batch item modification, one can modify or delete a subfield. When deleting a subfield et modifying another, the wrong subfield gets modified.
Comment 2 Fridolin SOMERS 2017-05-31 15:12:10 UTC
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
Comment 3 Fridolin SOMERS 2017-05-31 15:14:28 UTC
This bug also appears with no background job Bug 17240. We use this for nginx + plack
Comment 4 Fridolin SOMERS 2017-05-31 15:20:48 UTC
Created attachment 63880 [details] [review] Bug 18710 - batchMod-edit.tt is missing form end tag
Comment 5 Lee Jamison 2017-06-02 18:32:28 UTC
(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.
Comment 6 Josef Moravec 2017-06-05 11:05:01 UTC
(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...
Comment 7 Josef Moravec 2017-06-05 11:05:45 UTC
But I am not able to reproduce this issue...
Comment 8 Lee Jamison 2017-06-05 13:40:57 UTC
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.
Comment 9 Baptiste 2017-06-05 15:31:41 UTC
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.
Comment 10 Lee Jamison 2017-06-16 16:49:33 UTC
Unfortunately still unable to replicate the problem without a concrete, repeatable test case.
Comment 11 Macon 2017-06-23 03:17:24 UTC
Was able to test during KohaCon 17 with Lauren of SIL and Paul Poulain as the mentor.
Comment 12 Nick Clemens 2017-06-23 11:14:21 UTC Comment hidden (obsolete)
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
Comment 13 Lee Jamison 2017-06-23 11:37:25 UTC
(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 :)
Comment 14 Nick Clemens 2017-06-23 13:36:11 UTC
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