Steps to reproduce:
- Create a form view with a `div` with class `oe_button_box` and an
invisible modifier inside a `sheet` tag
- Open the form view
=> The invisible modifier is not applied on the button box.
Since https://github.com/odoo/odoo/pull/116641, the invisible modifier
set on a button box inside a sheet tag is **replaced** by a condition
that check if the form is displayed in a dialog. This is not correct,
the invisible modifier should be **extended** with the dialog condition.
closesodoo/odoo#141259
X-original-commit: 570a1a9bf3e7c3012c516beb8850f320a6cc8f63
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In many situations, when you click on a button, you want to disable all
the other buttons while it is running.
Currently, in each of these situations, we duplicate the same code that
disabled all the buttons and enabled them afterwards. Unfortunately, in
many cases, if the code executed crashes, the buttons are not enabled.
In this commit, we're going to create a helper so that we have a single
version of the code that correctly handles crashes. This helper will
disabled all the buttons, then execute the click code and enabled all the
buttons afterwards. If the code crashes, it will also enbaled them.
The problem has been reported for the Settings Form view:
When you edit this view and click save, if an error occurs in the save,
all the buttons remain disabled.
closesodoo/odoo#140938
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a many2many_tags field with onchange and on a slow network, quickly
add or remove tags several times. Each call to update sends a command 6
(SET) based on the current state of the record (typically here,
the very initial state). For example, if there're 2 tags [1, 2] in the
relation and I add 3, a command 6 with ids [1, 2, 3] is sent. If I
quickly add 4 before the onchange returns, another command 6 with ids
[1, 2, 4] is sent. At the end, 3 would not have been added to the
relation.
With this commit, we don't use the command "set" anymore. Instead, we
use a combinaison of commands "link" and "unlink" to add and remove
records from the relation. This way, we don't need to know the current
state of the record, and we can be sure that the final state of the
relation is the one we expect.
Task-id 3522153
closesodoo/odoo#140644
Related: odoo/enterprise#49995
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes an issue with the domain field where a traceback would
be launched when an invalid domain is received. It also changes how
invalid domains are displayed in foldable domain fields so that only the
content of the domain selector component is displayed in this case.
closesodoo/odoo#140719
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit changes the behavior of the domain field such that it
performs a quick validation of the domain after it has been edited in
the debug input. This solves an issue where the isValid state was not
properly updated after debug input edition.
Part-of: odoo/odoo#140719
In views with a searchbar, we want the filters to be displayed
directly when they are activated, without waiting for the view to
be reloaded. This is to provide a direct feedback to the user.
Before this commit, this didn't work in grouped kanban view with
progressbar. The regression has been introduced by [1] which moves
the progressbar logic out of the model. With [1], the rendering of
the KanbanController waits for the progressbar data to be loaded
in onWillUpdateProps, thus delaying the rendering coming from the
WithSearch when a filter is toggled.
This commit applies the same logic as for the model: we do not wait
for the loading promise in onWillUpdateProps. That way, the
rendering coming from WithSearch is synchronous, but a reload is
initiated and another rendering will be scheduled by the Controller
itself when the data will be loaded.
This commit also adds a test for the model case, as it appears that
this wasn't tested.
[1] 58ca40b032closesodoo/odoo#139967
X-original-commit: 47cf6e326f5a795984bac2138b169503c3dd099c
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Purpose:
-------
The "StockMoveX2ManyField" custom field has given rise to a new need,
that of being able to edit a record in an x2many directly or from a dialog.
This is the first use case to require the ability to do both at the same time.
This particular use case highlighted a bug preventing a change from being saved.
How to reproduce:
- Go to a form view with an x2m using a custom widget
- Open an x2m record in dialog mode
- Close the dialog
- No changes have been made to the record, so the save button is not displayed
- Edit a field in the same record
Before this commit:
The save button is not visible
After this commit:
The save button is visible.
closesodoo/odoo#140298
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Purpose:
--------
Before this commit, if you edit a char field with an onchange in
an x2many, the FormStatusIndicator buttons will flicker.
How to reproduce:
-----------------
- Go to a form view with an x2many field in list mode
- Type a char in the char field of a record
- The FormStatusIndicator buttons are visible
- Click outside the char field
- An onchange is triggered
Before this commit:
The FormStatusIndicator buttons will disappear until the onchange returns.
After this commit:
The FormStatusIndicator buttons remain visible.
closesodoo/odoo#140179
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Tooltip items are not correctly sorted anymore after migration to last
Chart.js version in the commit eb530b83b06a057f96.
This feature is fixed in this commit.
task-3552948
closesodoo/odoo#139676
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit removes the requirement that the records count should be
set before the edit domain button is shown for domains which must be
edited in a dialog. This could be annoying in cases the records count
loads slowly.
task-3561782
closesodoo/odoo#139969
X-original-commit: f2ba825eac5e4bda3d1b1d3676a1b737701c0fb8
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Purpose:
--------
From the new RelationalModel (odoo/odoo#114024), in the list view, when
all the records are selected, the ListController is rendered once per record.
This causes performance problems and can cause a flicker where each record
is selected one by one.
Why:
----
When selecting all records, we will call record.togggleSelection() on each
record but this function uses a mutex. So each record will be selected
asynchronously. As the state is not modified by the same tick,
a rendering will be triggered for each call to record.togggleSelection.
Solution:
---------
Add a togggleSelection function to the DynamicList which will select all
the records in the same mutex. The state will therefore be modified in
the same tick and there will be a single rendering.
closesodoo/odoo#139859
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When ReferenceField uses an M2O field. The model is not updated along
with the props when the model field is updated.
Because of this, the onWillUpdateProps hook will keep trying to update
its value. This results in an infinite render loop.
task-3248500
closesodoo/odoo#139954
X-original-commit: f8f6aaa5e32967d6c7cd888fbe574acdc6f79dc6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Currently, users who want to change the visibility of product's
documents need to open their form view and edit it.
The selection widget now allows users to quickly edit the way a document
is displayed to their customers from the product's documents kanban view.
Part-of: odoo/odoo#137975
Before this commit, the KanbanRenderer was rendered twice.
Why:
---
The "getGroupsOrRecords" function used in the KanbanRenderer templace
uses the "sort" function on "list.groups". The "sort" function modifies
the array on which it is called, which will generate a rerender because
"list.groups" is reactive.
Solution:
---------
Call the "sort" function on a clone of "list.groups".
closesodoo/odoo#139547
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is a backport of odoo/odoo@f065276a46
Before chrome 116, programmatic clicks on disabled buttons weren't
actually fired. With chrome 116, they are. As a consequence, some
tests fails on chrome 116 because they click (on purpose) on
disabled button to highlight the fact that nothing happens.
This commit improves the click helper to make it throw an error
when the target is disabled. It also adapts the tests that were
clicking on disabled button, in general to simply assert that the
button is disabled instead.
closesodoo/odoo#139537
X-original-commit: 0e8b50d540c9eee0837282883d603937b94b2fd2
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit fixes breaking calendar view tests after the revamp done in
task-3455051 and task-3389317.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit adds the feature of saving the calendar state in the user’s
session storage. This allows the user to refresh the page and the sidebar will
be hidden/shown depending on what is saved in the session storage.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit adds date information in the calendar header depending on the
scale that is being rendered. E.g. in yearly view, we show the year; in
monthly view, we show the month and year; in weekly view, we show the month,
the year and the week number; in daily view we show the day, the month and the
year.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
What's new:
- The overall style is softer, the borders lighter
- The event's colors are less bright
- In month view: The AllDay events and multiple day events are block
colors while the events with start/end times on a single day have a
colored circle.
- A header hosts the date title and navigation buttons (which were in
the sidebar)
- The sidebar is narrower and collapses
We've fixed the height issues giving us double scrollbars in some views.
The sidebar, when long, was pushing the content beyond the frame giving
us extra scrollbars. This has been fixed with a CSS grid and
`overflow-y` on the proper elements.
task-3389317
Part-of: odoo/odoo#138670
In some modules at Odoo we want to have custom headers for calendar. Since
fullcalendar accepts a function callback that should render the header, it was
decided to have this method exist in the calendar_common_renderer. So any
other apps that want to add something to the header, can just extend this
method. This commit also changes how homeworking changes the header so that it
complies with this change.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
In google calendar, events in the past are shown with a reduced opacity. This
makes it easier to differentiate which events are past or not. This commit
implements the same feature.
task-3455051
task-3389317
Part-of: odoo/odoo#138670
This commit adds the feature of saving the calendar scale in the user’s session
storage. This allows the user to refresh the page and land in the same scale as
he had before. Also, if you switch apps, the calendar views will use the scale
saved in the session storage (unless a default scale is set using the mode
attribute).
task-3455051
task-3389317
Part-of: odoo/odoo#138670
steps to reproduce:
in a tree view export a large amount of data (or add a sleep in
/web/export/xlsx)
before this commit:
button is not disabled, allowing users to spam the button
after this commit:
button is disabled, informing the user that we're processing
his request
closesodoo/odoo#139392
X-original-commit: 56853574e10e8cf7d1dcec450db79d96d790f231
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Steps to reproduce
==================
- Go to budget analysis
- Switch to the pivot view
- Unselect the first three measures
- Save the current search and set it as default
- In the measures dropdown, there is only two measures remaining
Cause of the issue
==================
- When `context.pivot_measures` is used, the measures are computed from
it and those that comes from the metaData are missing.
opw-3544823
closesodoo/odoo#139315
X-original-commit: b11266cc377fa4753a0ee609258d9919f1ba5496
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit is part of a serie of commits which aims at simplifying and
reorganizing js files in the web addon
closesodoo/odoo#139156
Task-id: 3508223
Related: odoo/enterprise#49212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose:
--------
The "KanbanPropertiesField" has been renamed to "CardPropertiesField".
For consistency, the key "view_in_kanban" of the properties definition
is renamed to "view_in_cards"
Task-3458627
Part-of: odoo/odoo#132578
Purpose:
--------
This commit rewords the "KanbanPropertiesField" to "CardPropertiesField"
and add it as widget to use for properties fields in calendar views.
The rationale is that the "Show in cards" option of properties should
allow to enable the visibility of properties in kanban cards and in
calendar popovers (as it is currently the case in knowledge).
Task-3458627
Part-of: odoo/odoo#132578
Since https://github.com/odoo/odoo/pull/137098, we add a fallback for
false display_name in the form view, but we didn't add it for the list
view which doesn't instantiate the Many2one component. It uses
`formatMany2one` instead. Fix it to be consistent with the Many2one
closesodoo/odoo#139215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Since https://github.com/odoo/odoo/pull/137098, in
`Accounting > Bank > Tree View`, you get a traceback if one of the bank
statements in the view has a false as `display_name` (name is only
required in the view not in the model). The traceback comes from the
`extraLines` accessor in the Many2one component. The fix is the same
as in https://github.com/odoo/odoo/pull/138061 (FW of the first PR).
Part-of: odoo/odoo#139215
Before this commit, if you click twice on a record in x2many, two dialogs
are opened containing the same record.
Solution:
=========
Prevent a record from being opened as long as a record in this x2many
is already open.
How to reproduce:
=================
Go to a form view with an x2many
Click on the first record in the x2many
Click a second time on the record of the x2many (before the dialog is opened)
Before this commit:
-------------------
Two dialogs are opened with the selected record
After this commit:
------------------
Only one dialog is opened with the selected record
closesodoo/odoo#138984
X-original-commit: 31a9b13
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce
==================
- Install purchase_product_matrix,web_studio
- Go to purchase
- Click on a record
- Open studio
- Click on the "Products" tab > Edit List view
- Edit the product field
- Widget: Many2one
- Disable creation: enabled
- Close studio
- Create a new record
- Add a new line
- Type some random text in the product field
-> The option create is available
Cause of the issue
==================
When the can_create attribute is not passed, the `canCreate` ends up
undefined. This means the default value of true is used and the
`no_create` option is ignored.
The can_create attribute should actually be passed and there is a bug in
python in the `_editable_tag_field` function, but it is not something we
can change in stable due to the fact it it requires an explicit change
in some views to pass the validation and thus, this requires an addon
upgrade (`-u ...`).
See https://github.com/odoo/odoo/pull/138032
opw-3432903
closesodoo/odoo#139068
X-original-commit: 4b6756e1775488e230bc25767adf5744f0ea9149
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, adding more records to a many2many field than the
limit of the pager did not update the pager. This commit fixes this
issue by updating the limit of the pager.
closesodoo/odoo#138883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the status bar field could be displayed in 2 ways:
- in small screens: as a dropdown
- in larger screens: as an inline list of buttons
This commit centralizes both of these approaches into a dynamic display
that fits the available space:
- the current stage is always displayed;
- previous stages are displayed behind or contained in a dropdown if not
enough space;
- next stages are displayed behind or contained in a dropdown if not
enough space.
Task 3336856
closesodoo/odoo#124267
Related: odoo/enterprise#48706
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit removes all the legacy envs (common_env, env, public_env)
as well as the files used to set up them.
task 3439226
closesodoo/odoo#138348
Related: odoo/enterprise#48781
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
We improve various aspects of the domain selector:
- We make the domain selector be able to display all domains accepted by the class Domain (domain.js)
- We improve the edition/selection of values, e.g. for the operators in/not in
- We improve/simplify the style/dom
Task IDs: 3507123, 3508940
closesodoo/odoo#128680
Related: odoo/enterprise#48324
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Notté <mano@odoo.com>
We move the filterable widget from loyalty to web to make it more widely
accessible to other applications. It will soon be used in the new activities
plan feature.
Following the move of the filterable selection widget to the web module, we do
some light cleanup.
Task-3390865
Part-of: odoo/odoo#137969
The goal of this commit is to cause a recalculation of specialData when
this depends on a record value.
Currently, specialData are only calculated during onWillStart and
onWillUpdateProps. But the specialData of certain fields do not depend
only on the props, they can also depend on the values present in the record.
We therefore want to recalculate them when the value of the record changes.
How to reproduce:
- Go to a form view with a field "x" and
a field with specialData dependent on field "x".
- Edit the field "x"
Before this commit:
The specialData have not changed
After this commit:
The specialData have been recalculated.
closesodoo/odoo#138372
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to resolve two issues relating to the properties field:
Issue 1:
========
In a list view, when you edit a property and then select another field
in the same record, the edition disappears.
How to resolve:
--------------
Do not delete the changes linked to the property in record.update.
How to reproduce:
----------------
- Go to a list view with a properties field containing a property char
- Insert a value in the char property
- Click on another field in the same record
Before this commit:
The inserted value disappears
After this commit:
The inserted value is still present
Issue 2:
========
The fields/activeFields only take into account properties received
during the initial web_read and not those added by an update or an onChange.
How to resolve:
--------------
Generate property fields and activeFields during parseServerValue
(web_read and onChange) and during an update.
How to reproduce:
----------------
- Go to a form view with a properties field
- Editing a field with an onChange
- The onChange returns a new property for the properties field
Before this commit:
A crash is displayed
After this commit:
The new property is displayed correctly
closesodoo/odoo#137989
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The help defined on a field via Studio is only visible when debug mode
is enabled
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts, open a contact and toggle Studio
3. Add a field in the form view and add a message in the Help Tooltip of
the field
4. Close Studio
5. Without debug mode, the small question mark is not displayed next to
the field so we cannot see the help tooltip
Solution:
First use the help defined on the field in the view, then the help
defined on the field in the model
Problem:
The tooltip help can also come from the view
opw-3511121
closesodoo/odoo#138416
X-original-commit: a70639b790471aec781c50274abbda78bf5bea7d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit adds the recently removed add condition button to the folded
domain field so the user can unfold the domain and add a new rule in one
click.
Task-3525269
closesodoo/odoo#137663
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit renames calendar's attribute quick_add to quick_create
to be more consistent with other views.
closesodoo/odoo#138042
Related: odoo/enterprise#48677
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the PR [1], quick_add can be both a boolean and an id:
0 = without quick create
1 = with quick create and simple dialog
other number = with quick create and custom form view dialog
This is not great to have both behavior in a same attribute so this
commit split them back in two attributes as it was before [1].
It's easier to understand when we want a quick create and which view
to use in the dialog.
[1]: https://github.com/odoo/odoo/pull/122923
Part-of: odoo/odoo#138042
Purpose:
--------
When the property field is added into a form view, the "add a property"
button is shown by default.
However, most of the time the users won't add properties when opening a
form view, making this button take up space for nothing.
To alleviate this issue, commit [1] added an option that allows to hide
this button, and added actions to allow adding properties from the cog
menu instead.
Now that properties are being added into several views, one would like
this "add properties" button to be hidden by default, and show an entry
in the cogmenu allowing add properties by default, without needing to
create an action for every view using a property field.
Therefore, a new static action "Add Properties" has been added in the form
controller that is available if a properties field has been encountered
during the parsing of the form view's arch.
The "hideAddButton" has been changed into "showAddButton" and now allows
to show the "Add a Property" by default.
Task-3458627
[1]: https://github.com/odoo/odoo/commit/1f80810e39f811122a65e11cd8cac99aa39a7960
Part-of: odoo/odoo#137589
The previous commit reverts the ORM fallback of `display_name`. Then the
`display_name` can legitimately be `False` again. But the `Many2one` and
`Many2XAutocomplete` components don't handle this case (and generate a
traceback see task-3424154).
This commit adds the same fallback ('Unnamed record') for these two
problematic components; one when the name_search returns `False` as
`display_name` (autocomplete for Many2Xfields) and another when we read
the many2one `display_name`. This name is not user friendly, but for
the business model it shouldn't happen anyway. It is also better than
the empty string which is confusing with no value. Note that there is
already a fallback for `display_name` that is used in the broadcrumb
(https://github.com/odoo/odoo/blob/50b2a24f22cb470bcc1a9befe677cf794211d7b2/addons/web/static/src/views/form/form_controller.js#L282).
Part-of: odoo/odoo#138061
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, creating a record in Calendar view that has a
properties field in its form view causes a crash.
How to reproduce:
----------------
- Go to the Project app
- Go to a task
- Add a property
- Go to the Calendar view of the project
- Create a record
Before this commit:
An error is displayed
After this commit:
The form dialog opens so that you can create the record
closesodoo/odoo#137828
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to resolve:
=====================================
1. When you edit a Char or Boolean field with an onChange that returns
the value before editing, you must display the value of the onChange.
2. In the model, html fields are always Markup fields. But when we evaluate
a modifier containing an html field, we use the server value (a string or false).
3. When we edit a field and its onChange returns an server error, we want to
revert its value to the valuea before edition.
Solution:
=========
1. Always render when applying a change, even if the value does not change,
because onChange returns the initial value. To do this, we'll apply
the changes to record.data, then apply the changes from onChange.
The value will therefore change, which will cause all the components
observing the value in record.data to render.
2. When we update an html field, its value will always be markup and
we'll store it as a string in _textValue so that we can evaluate the
modifiers without the markup. For changes coming from the onChange, we
will store the value in _textValue and apply markup on it for record.data.
3. When an onChange returns an server error, we will apply the changes and then
revert them directly. This will have the effect of triggering a rendering
on all the components observing to the record.data corresponding to
the changes and so displaying the values before editing.
How to reproduce:
=================
Case 1:
------
- Go to a form view containing a boolean field with an onChange
- Check the boolean field
- The onChange returns with the value false
Before this commit:
The boolean field is always checked
After this commit:
The boolean field is no longer checked
Case 2:
------
- Go to a form view containing an html field and an field "x" with
invisible ="not html_field" and an onChange
- Edit the field "x"
- The onChange returns the value false for "html_field".
Before this commit:
The field "x" is always displayed
After this commit
The field "x" is no longer displayed
Case 3:
------
- Go to a form view containing a char field with an onChange
- Edit the field
- onChange returns a server error
Before this commit:
The field is marked as invalid and contains the value after editing.
After this commit:
The field contains the pre-edit value
closesodoo/odoo#136924
Related: odoo/enterprise#48515
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Pierre Rousseau