Saas 12.3 list multi save fix aab #36522

Backport of 801c603 Pressing ENTER on a button element triggers an additionnal 'click' event. Since this 'unwanted' click caused some issues in a few cases, we prevent it. Moreover, there isn't currently any known case in which this event is useful. Before this commit: No modification of the initial behaviour on ENTER key After this commit: ENTER key pressed in abstract fields has its default behaviour suppressed

Backport of 1f2c640 Adding a line in grouped listviews caused a crash in some cases. Steps to reproduce: - go in any grouped editable list view - click on any "Add a line" cell, but not on the link itself - press ENTER Before this commit: A crash occured. Unable to add a new line. Needed to refresh the page. After this commit: Line addition functionnality properly working even when selecting the outer cell

Backport of 10eaf74 Fixed crashes/incorrect behaviours in multi edition in the list views. The solution to these problems was mainly to refactor the function used to save multiple records. Before this commit: - Cancelling the confirmation dialog in multi edition caused the edited record to be editable but disabled - Saving an empty field in multi edition triggered a JS error - Static confirmation message ("saving 0 valid records") After this commit: - Ability to cancel confirmation - Proper error display when trying to save empty fields - Message consistent with the situation

Backport of 4b7ba86 After editing multiple record, we want don't want any record selected. This commit ensures that.

Let's assume an editable list view with a many2one field and 2 records: the first one has value 1, the second value 2. The user selects all records and wants to set their many2one to value 1. It edits the first one, sets 1 and validates the confirm dialog. Before this rev., it didn't save anything because the 'reference' record (the one used to edit), didn't actually changed, as we reset the same value. This rev. forces the write the new value on all selected records in that case. Task 2068280

Fixes the way records are discarded in list views Before this commit, clicking the "Discard changes" button in a list view after editing a record triggered both the "field changed" and the "discard changes" methods (resulting in 2 modals opening). Now, all fieldChanges are prevented when trying to click "Discard changes", and are re-applied if the click was unsuccessful (lifted left mouse button somewhere else). Task 2068280

Fixes the way many2one fields are rendered in editable list views. Before this commit, many2ones in readonly mode would render as links and their widget would be considered as active even though you couldn't edit it. Now, they are rendered as plain text and act the same way as readonly char fields.

...when validating last row by pressing ENTER. In single edition, we automatically add a new row when the user edits the last one and presses ENTER. This is something we don't want in multi edition. Task 2068280

Before this commit, if a record was selected and another one was edited, it was considered as multi edition. Now, the multi edition only works if the edited record is included in the selection; else it will be the only edited record (single edition). Task 2068280

Having those inputs enabled can lead to weird situations where a record has been modified but can't be saved anymore (because the user clicked on one of those record selectors to focusout the edited row). Also we don't want the user to start multi-editing a field, then change the selection, and then validate the changes. Task 2068280

Before this rev., the 'fieldChanged' event was triggered each time the user selected a value (a day, an hour, a minute or a second) in the datepicker. This means that if there was an onchange on the field, a lot of RPCs could have been done when a user set a datetime. In addition, in a list view with multi edition, the user was asked to save the changes at each step of the datetime selection, making the feature unusable. Task 2068280

The Date(Time)Fields listen to 'input' and 'change' events (like all InputFields) to keep track of changes. However, the datepicker already listens to the 'change' event. As a consequence, in multi edition in a list view, if the user changed the value of a date(time) field by directly editing the input, the fieldChanged event was triggered twice, and there were 2 dialogs asking the user if he wanted to save the change. This rev. makes the Date(Time)Fields stop listening themselves to 'input' and 'change' events, and instead completely rely on the datepicker widget. Task 2068280

Gave back focus to the last edited cell to increase usability with key nav. Before this commit, after saving several records with multi edition in a list, focus was lost (given to the body). Now, last edited cell is given back the focus after multi editing.

Onchanges make no sense in multi edition as they would be computed on the 'reference' record (the one use to edit), but applied on all selected records. This rev. simply disables them in that case. Task 2068280

This rev. solves the similar issue as 801c603, but with boolean fields. Scenario: select several records, select a boolean cell, press enter to change the boolean value. Task 2068280

Gives time to the user to enter an actual value in m2o in list views. Before this commit, emptying a many2one field (selecting all > BACKSPACE or DELETE) triggered instantly a field_change. This was an issue in multi edition as a field changed triggered instantly a save on selected records without giving time to the user to enter a new value. Now, many2ones only trigger a fieldChange when selecting a new valid value.

Added handling of invalid format types in multiple edition in list views. Before this commit, in multiple edition, a field that was edited with an invalid value format (e.g. a numeric field receiving a string value) didn't trigger a field_changed and no prompt was shown; the record was simply idle with an dirty value. Now, the list controller also listents for set_dirty events and automatically triggers an error modal + discards all changes when receiving one.

Changed the way the header selector behave when the selection changes. Before this commit, the header selector was only checked when clicked and was unchecked as soon as any other record was unchecked. Now, the header selector reflects the current visible selection: if all of the other visible selectors are checked, it will be checked. Folded records are not considered visible, thus only records from active groups and from the current pager will be taken into account.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Saas 12.3 list multi save fix aab #36522

Saas 12.3 list multi save fix aab #36522

Commits on Sep 18, 2019