Bug 22669

Summary: Cannot edit received item in acquisitions with acqcreateitem set to "when placing an order"
Product: Koha Reporter: Liz Rea <wizzyrea>
Component: AcquisitionsAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: blocker    
Priority: P2 CC: gmcharlt, jonathan.druart, katrin.fischer, martin.renvoize, nick, wizzyrea
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22762
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
19.05.00
Bug Depends on: 22762    
Bug Blocks:    
Attachments: Bug 22669: Fix item editing on receiving an order
Bug 22669: Fix item editing on receiving an order
Bug 22669: Fix item editing on receiving an order

Description Liz Rea 2019-04-08 22:32:40 UTC
To replicate:

Make sure acqcreateitem is set to "when placing an order"
Create a basket with some orders
close the basket
Go to your vendor and receive an order
On the receive page, try to edit your item, the pop up page will open and then close, not allowing the item to be edited.
Comment 1 Jonathan Druart 2019-04-24 03:07:55 UTC
Caused by
  commit 31c29fd31f557306233e6a2936148a5bb10b89a1
  Bug 21206: Replace C4::Items::GetItem
Comment 2 Jonathan Druart 2019-04-24 03:08:14 UTC
The log says: The method Koha::Item->collection is not covered by tests!
Comment 3 Jonathan Druart 2019-04-24 03:11:33 UTC
The explosion has highlighted an older problem.

Since
  commit bb1e9c500c810402c64436c53bcc00ffb9a0b857
  Bug 17248 - Koha::AuthorisedValues - Remove GetKohaAuthorisedValueLib
the "Collection code" is not filled correctly (items.collection vs items.ccode).
Comment 4 Jonathan Druart 2019-04-24 03:48:19 UTC
Scratch the last 3 comments, they are for another bug report.

It has been introduced by
  commit 1253975389975a8ff11a9bb2ef84582aeb6bd08b
  Bug 21091: Move add item template JavaScript to a separate file

And the one to blame is JavaScript (remember, "0" is evaluated to true)
Comment 5 Jonathan Druart 2019-04-24 03:58:24 UTC
Created attachment 88586 [details] [review]
Bug 22669: Fix item editing on receiving an order

Since
  commit 1253975389975a8ff11a9bb2ef84582aeb6bd08b
  Bug 21091: Move add item template JavaScript to a separate file

items cannot longer be edited when receiving an order.
When moving the code to the JS file, the JS variable "opisadd" was
always set to "true":
  var opisadd = '[% opisadd | html %]';
Even if the TT variable is 0, opisadd will be "0", which is evaluated to
true in Javascript

To clean the situation it is easier to remove this variable and use "op"
instead.

Test plan:
- Make sure acqcreateitem is set to "when placing an order"
- Create a basket with some orders
- Close the basket
- Go to your vendor and receive an order
- On the receive page, try to edit your item
=> Without the patch, the pop up page will open and then close, not allowing the item to be edited.
=> With this patch applied you will see the item edit form. Save and
confirm that the parent window is updated with the new value (actually
it's refreshed)
Comment 6 Jonathan Druart 2019-04-24 04:00:46 UTC
Comments 1 to 3 addressed on bug 22762.
Comment 7 Katrin Fischer 2019-04-24 05:44:01 UTC
Thx, Jonathan!
Comment 8 Liz Rea 2019-04-24 18:54:34 UTC
Hi Jonathan,

It all seems alright until we save the item - the window/tab doesn't close and the receive window doesn't seem to update.

Have another look?

Cheers,
Liz
Comment 9 Jonathan Druart 2019-04-24 20:09:11 UTC
Hi Liz, thanks for testing.
The window closes correctly here, make sure you refreshed the cache.
However the data are not updated, because of the "method not covered by tests" error, with the patch from bug 22762 it looks ok.
Could you retest with both patches applied?
Comment 10 Claire Gravely 2019-04-25 10:25:33 UTC
Created attachment 88746 [details] [review]
Bug 22669: Fix item editing on receiving an order

Since
  commit 1253975389975a8ff11a9bb2ef84582aeb6bd08b
  Bug 21091: Move add item template JavaScript to a separate file

items cannot longer be edited when receiving an order.
When moving the code to the JS file, the JS variable "opisadd" was
always set to "true":
  var opisadd = '[% opisadd | html %]';
Even if the TT variable is 0, opisadd will be "0", which is evaluated to
true in Javascript

To clean the situation it is easier to remove this variable and use "op"
instead.

Test plan:
- Make sure acqcreateitem is set to "when placing an order"
- Create a basket with some orders
- Close the basket
- Go to your vendor and receive an order
- On the receive page, try to edit your item
=> Without the patch, the pop up page will open and then close, not allowing the item to be edited.
=> With this patch applied you will see the item edit form. Save and
confirm that the parent window is updated with the new value (actually
it's refreshed)

Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Comment 11 Kyle M Hall 2019-04-25 11:46:48 UTC
Created attachment 88756 [details] [review]
Bug 22669: Fix item editing on receiving an order

Since
  commit 1253975389975a8ff11a9bb2ef84582aeb6bd08b
  Bug 21091: Move add item template JavaScript to a separate file

items cannot longer be edited when receiving an order.
When moving the code to the JS file, the JS variable "opisadd" was
always set to "true":
  var opisadd = '[% opisadd | html %]';
Even if the TT variable is 0, opisadd will be "0", which is evaluated to
true in Javascript

To clean the situation it is easier to remove this variable and use "op"
instead.

Test plan:
- Make sure acqcreateitem is set to "when placing an order"
- Create a basket with some orders
- Close the basket
- Go to your vendor and receive an order
- On the receive page, try to edit your item
=> Without the patch, the pop up page will open and then close, not allowing the item to be edited.
=> With this patch applied you will see the item edit form. Save and
confirm that the parent window is updated with the new value (actually
it's refreshed)

Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 12 Nick Clemens 2019-04-26 12:41:49 UTC
Awesome work all!

Pushed to master for 19.05
Comment 13 Martin Renvoize 2019-04-26 15:52:44 UTC
Bug not in 18.11.x series