Bug 18710

Summary: Wrong subfield modified in batch item modification
Product: Koha Reporter: Fridolin SOMERS <fridolin.somers>
Component: ToolsAssignee: Fridolin SOMERS <fridolin.somers>
Status: Failed QA --- QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: baptiste.wojtkowski, caballeromaricon, josef.moravec, ldjamison, nick
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18730
Whiteboard:
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: 18706, 18707    
Bug Blocks:    
Attachments: 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 1 Fridolin SOMERS 2017-05-31 15:04:59 UTC
Needs Bug 18706 and Bug 18707 to be tested.
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)
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