Bug 33846 - 'Save' and 'close' buttons confusing on multi-receive
Summary: 'Save' and 'close' buttons confusing on multi-receive
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 8179
Blocks:
  Show dependency treegraph
 
Reported: 2023-05-26 13:46 UTC by Tomás Cohen Arazi
Modified: 2023-05-30 21:17 UTC (History)
8 users (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 Tomás Cohen Arazi 2023-05-26 13:46:38 UTC
I'm opening this so we don't forget.

Talking with Kyle and Nick, we agreed the 'Save' button is weird, in the sense that it is not saving but updating the underlying table which can then be used to receive. And there's the 'Close' button, that seems to be doing the same thing i.e. closing the modal.

Plus, there's no real way of 'resetting' your changes which is the usual thing we have: a confirm button and a cancel.

I'm not sure what is the best solution here, but we could have:

- Close (which updates the underlying table)
- Cancel link (which resets any changes you've made)
Comment 1 Jonathan Druart 2023-05-30 07:32:54 UTC
Close is not saving, simply closing the modal. Saving is effectively saving the change you made in the modal.

At least it is their intended behaviours.
Comment 2 Nick Clemens 2023-05-30 13:24:24 UTC
From what I found in the code, save mostly just closes the window.

All of the inputs on the form have events attached - when the value is changed we update the row in the background
Comment 3 Jonathan Druart 2023-05-30 13:51:11 UTC
In my understanding we effectively save the data stored in the "row" data of #order_edit when we click "Save": see onclick event on .modal-save which is calling save_rows
Comment 4 Tomás Cohen Arazi 2023-05-30 17:33:16 UTC
When the modal opens, a copy of the underlying row is stored in the 'row' data element of the #order_edit element which is the modal itself. That data element is kept in sync with the events you mention, Nick. Not the 'real row' on the underlying table.

And the 'real row' is synced using the `save_rows_()` function, looping through the 'real rows'.

Nick: are you suggesting a more subtle issue? Like the row being stored as a reference to the one in the modal and causing issues?
Comment 5 Tomás Cohen Arazi 2023-05-30 17:34:49 UTC
I meant `keep_row()` not `save_rows()`.
Comment 6 Katrin Fischer 2023-05-30 21:17:56 UTC
Talking about the buttons: I feel like it might be more intuitive to have previous and next buttons next to each other on the left. I want to skip back and forth and now I have to 'move' over the other buttons each time.