- Install two languages;
- Install Accounting;
- Active 'Default Terms & Conditions';
- Select 'Add a Note';
- Click on the translate button;
- Answer 'Ok' when asking for saving the settings before modify the
translation;
- Save or Discard the translations;
- Save the settings.
Before this commit, a backtrace is raised. This issue raise because we
create twice the settings record. One before opening the translation and
the second time juste before saving the settings. This is a normal
behaviour in settings, as we consider the settings view as always new, a
new record is always created. But, only the last one should be sent to
the python code on the resId array.
opw-3109677
closesodoo/odoo#109803
X-original-commit: 5394f4c82829f8c7e6aaf73ddb1590f316f87ee3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
Before this commit, the confirmation dialog was opened
only when the user clicked on an action button.
Now, the dialog is also shown when the user clicks a
menu item in the navbar.
Of course this dialog is shown only if the user has
changed a setting.
closesodoo/odoo#110194
Task: 3102800
X-original-commit: a180178bfd73d6e5f95ee5a9e9cdc1b0d64fc574
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a user was on a form view with pending changes
and would click on the browser back button. If the previous action was
the same action, the user would be redirected to the form view but a
traceback would be raised because the form view was not able to handle
the pending changes "in time".
Here "in time" means before the form view is rendered. The form view
when rendered will try to update its display name through its controller
config, but as the new controller will be in fact the same as the
previous one, its config is currently being changed while the previous
form view is still using it. This leads to a traceback.
This commit fixes this issue by making sure that the changes are
properly commited before changing the config for the new controller.
The same kind of issue has been fixed in the action service for the
restore function, but there are no sensible ways to test this particular
use case.
closesodoo/odoo#109653
X-original-commit: e8a95c37e4e9ee4e4a65a3bfb216d3fa55544933
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is to convert the client actions in misc.js into the new
architecture.
We remove the client actions login and logout because they are no
longer used in the code base.
closesodoo/odoo#109332
Task-id: 3099992
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup, i.e. construct some
fake groups. It also populate those groups by assigning them some
previously created fake records. It turns out that those fake records did
not have the right type when the first group by is a date/datetime field.
The record values created (during the group assignation) for that field
were luxon.DateTime instances instead of strings like "2022-12-15".
This was the root cause of the following problem.
Have a kanban view in sample mode and grouped on a date field, then
switch to a pivot view grouped on the same date field. A crash occures.
That crash is linked to the above mentionned problem in the following
way:
- open the kanban view (with sample="1" in its arch)
- some existing groups are fetched by the relation model but no records
exist
- the kanban view switches to sample mode and some fake invalid records
are created in the sample server (the invalidity of records do not
cause visible problems at that time)
- switch to the pivot view
- the sample server is reused but existingGroups is set to be null, so
that _mockWebReadGroup uses the invalid records to create the groups
it needs. The crash occures at that step.
Forward-Port-Of:: cdd583f74f51086c8d5f243a2a761622229ccc26
closesodoo/odoo#109031
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the modified test sometimes failed on runbot,
because it might happen that the hashchange event is triggered in
the next animation frame (the event isn't triggered synchronously).
This commit ensures that we wait for the hashchange event, and for
a nextTick before checking that the next action is in the DOM.
Fixes runbot issue 6946
closesodoo/odoo#109028
X-original-commit: 6aba445e2b4a1f6321cefb04fb07584df615dfa2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
**Before this commit**
When a breadcrumb is restored, the props resId is overwritten by the
res_id of the action.
**After this commit**
The props resId is kept if it is defined.
closesodoo/odoo#108996
X-original-commit: 810a1d29bfa7c497627a37e0cec64df51b75bb4b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit, the header of list views no longer scrolls with
the table, it remains visible on the top when scrolling.
Task 1917230
closesodoo/odoo#107631
Related: odoo/enterprise#35097
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
An act_url action in target "self" redirects the current window/tab
to the given url. It always reloads the page, except when only the
hash or query string changes.
This commit blocks the ui when the page reloads, because there's a
lack of feedback and interacting with the ui is unnecessary anyway.
For instance, module operations (install, remove and update) end
with page reload. During the operation, the ui is already blocked
because the operation takes time. After the operation and before
the page is actually reloaded, the ui is unblocked. As the reload
also takes time because of asset rebuilding, it makes false feeling
for the user that operation completes and interface is ready for
interaction. With this commit ui is blocked until the page is
reloaded.
closesodoo/odoo#107830
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
- On the settings view;
- Open the CRM settings;
- Click on "Update Probabilities" button;
- Change the "consider leads created as of the" date;
- Click on "Confirm" button;
Before this commit, the fields on the settings related to the dialog
were not updated. This occurs because, as the setting model is a
transient model, the settings view should always perform an onchange to
fetch the view, and it wasn't the case here.
Now, we patch the basic model used on the settings view to remove the
res_id, to consider the record always as new. This will always perform
an onchange to fetch the data. Note that, this hack is the same as it
was done before the owl migration.
opw-3073124
closesodoo/odoo#107879
X-original-commit: 792567c71aed626b5566f32b656104e3e70c496c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the setting search was done exclusively in some
selected texts. These texts needed to be on some specific selectors
(field, label, span.o_form_label and div.text-muted).
Now, all text on a setting are searchable (including the text in
buttons). This commit also re-structure the setting compilers file to
remove the functions outside the class, this is done to standardize the
compilers (setting, form and view).
closesodoo/odoo#107226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Some missing aria attributes from 14.0 are reintroduced.
They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).
closesodoo/odoo#106277
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Before in a legacy client action, using a link to change view and
going back to the client action with breadcrumb does not restore the
scroll position.
Now with this commit, the scroll position is restored when going back to``
the client action.
Steps to reproduce:
- Install Accounting
- Go to `Accounting -> Reporting -> Balance Sheet`
- Unfold the tree to make the window scrollable
- Click on a link at the bottom of the window
- Go back to Balance Sheet
closesodoo/odoo#105443
X-original-commit: 225e809aa3ce1c506be69287e8084adf877547d7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when compiling a form group, the scope class is
added to the elements of the outer group. It was added on the element
class attribute. The issue is that FormLabel don't have a class
attribute but a className attribute. So the class wasn't shown on the
DOM.
Now, the class is added on the FormLabel className attribute and shown
in the DOM.
closesodoo/odoo#105315
X-original-commit: 214beb39d7c1a315255f0a5a842e60f73e7900cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the labels tags that were after the fields losses
their attributes (i.e. classes) after the compilation of the form view
arch.
Now, the attributes are correctly copied after the compilation.
similar to : 873790f802
X-original-commit: 395bdf8880c5929652838a93351596b045708905
Part-of: odoo/odoo#105315
Co-authored-by: Patrick Hoste <pko@odoo.com>
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- Go to a list view with multiple items
- Click on an item
- Delete it
- Go back in history twice (Using the browser navigation) to return to the list view
-> We can't click on another record
opw-2854113
closesodoo/odoo#103808
X-original-commit: 92c90823139b413c8289d1c323ad694fc8220a61
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.
This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.
Fixing #74647 (from 16.0 to master)
closesodoo/odoo#103572
X-original-commit: 95f8266a5b84f5faa59a713019ab713392b3ef78
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have more than one Odoo module installed. Go to the Settings.
Scroll the first page.
Change the app in the sidebar.
Before this commit, the scroll position was the same for all modules (or apps, same thing).
It is not wrong per se, but when changing app, there is no reason that the scroll position of the former
is somehow correct business-wise.
After this commit, the scroll position is stored and restored on a per-app basis.
closesodoo/odoo#103369
X-original-commit: 01b16c392b888ceaccc8b0c95da142dbb90517ef
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a simple char field somewhere in res.config.settings.
Before this commit, when arriving on the settings form view, the settings page
was scrolled. This was because the standard FromRenderer has and used its autofocus feature,
thus focusing the first text field present in the view.
After that, the Settings form view gave the focus back to its search view input.
After this commit, the FormRenderer's autofocus feature is deactivated.
X-original-commit: 2c67b1dbe15d2cb77ee0b50514a4b9d41a006114
Part-of: odoo/odoo#103369
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
Before this commit, open an act window action asking for a tree view
would cause a crash. We fix that.
closesodoo/odoo#101831
X-original-commit: fa6fd8b079ad3347f3571654f07bf9751834654d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When an action was retrieved from session storage, the no content helper
content was not markuped. It would therefore display hmtl text on the
user screen.
closesodoo/odoo#101306
X-original-commit: 592b8016b8a44dc1775918e4ffbf572e9b02c50f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, we propagate all the slots to the SettingsPage. This
could raise an issue if the default slot (propagated) has a content, for
more information see: https://github.com/odoo/owl/issues/1256
Now, to avoid this, we only propagate the slots that are used on the
SettingsPage component, ie: NoContentHelper.
closesodoo/odoo#100362
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
From a (e.g.) list view, click on "Create". In the form view, fill
in some fields, but leave a required field empty. Click on the
breadcrumbs to come back to the list. Before this commit, a
notification was displayed (because some required fields are
unset), but we left the form to come back to the list anyway.
The desired behavior is to stay on the form view, and display a
notification indicating that some fields are invalid.
In legacy views, we rejected promises to indicate that we couldn't
leave. This is a pattern we tried not to use anymore in new code.
Instead, we return a promise (if the method is async obviously)
which resolves to a boolean value, indicating if it works or not.
As a consequence, the action service wasn't properly dealing with
new views, as the promises they return always resolve.
This commit fixes the issue by adapting the code in the action
service.
Part-of: odoo/odoo#100050
Before this commit, we didn't apply the default favorite (if any),
when there was an active_id or active_ids in the context. This was
a mistake. Note that it only impacted owl views.
closesodoo/odoo#99989
X-original-commit: 1e13e6cd073e57b3744caefc4b8f3795c35a4c10
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since owl now uses error chains/causes when errors happen in the owl
lifecycle, when an error happens in the owl lifecycle, the displayed
tracebacks generally only contain the stack trace of where owl called
the corresponding lifecycle hook.
This commit modifies the error service and the error utils so that now,
when completing/annotating a traceback, we also add the tracebacks
(annotated when appropriate) of the error cause chain, as it contains
valuable debugging information.
This commit also makes it so that the QUnit suite logs the source of
each test failure (which may be an error with a chained stack trace)
closesodoo/odoo#98157
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce:
- Go to settings
- Click on discard
-> the breadcrumbs contains twice the "Settings" entry.
This commit fixes the issue by restoring the legacy behavior in
the "Discard" button handler, that is, calling doActionButton with
the special="cancel" param. This had been changed by mistake during
the conversion of the settings form view.
To make the fix work, a slight changed has been done in the model
as well, as reloading a datapoint could lead to the creation of
a new datapoint (typically when it's a new record), so the handle
must be updated in this case.
closesodoo/odoo#99904
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following scenario:
- be on a list or kanban view with sample data
- click on "Create" (-> opens the form view)
- in the form view, there's a kanban x2many field
Before this commit, the no content helper was displayed in the
form view, whereas it obviously should not.
The issue occurred since [1], as this commit has the unwanted
since effect to set the property `useSampleModel` to true on the
form view model, which is used in the x2many kanban renderer to
determine whether or not to display the no content helper.
This commit forces that property to `false` on views that
explicitely ask to ignore sample data.
[1] 2600d1f2aeclosesodoo/odoo#99889
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Go to a (OWL) list view with sample data, click "Create" to open a (OWL)
form view and go back to the list view using the breacrumbs: the sample
data has disappeared.
This is due to the fact that the form view set useSampleModel=false in
the globalState when it is left while it does not use at all sample data
mode.
Here we make it simply pass the value that it received initially.
closesodoo/odoo#99587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit converts the report code to the new framework.
Since the module stock still has code that extends the old
"ReportClientAction", the old report code is put inside this module.
It can be then naturally removed once the module is fully converted.
closesodoo/odoo#97390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a text-muted on a setting (a description of the
setting) contains fields or HTML tags, the highlight generated wrong
texts.
Now, we highlight the text in an iterative way, taking care to only
highlight the text.
closesodoo/odoo#99205
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When searching a text of a hidden field (for example, "gate"), the
setting itself will not be shown, but the group title, and the app
Search Header will be shown.
This issue arise because, we use an if condition with all the label of
all the fields (hidden or not) in the group (or app) to decide if the
group title or the app header will be showed.
Now, we modify this to hide (d-none) the group title or the app header
if there is not a settings below them.
Part-of: odoo/odoo#99205
Previously, when a label in a form arch had an empty string attribute,
we would not render it at all as it seemed useless. In practice, some
existing form arch rely on empty labels being rendered for layout
reasons, and the corresponding views are now broken.
This commit fixes that by instead rendering an empty label, just as
legacy views used to.
Part-of: odoo/odoo#98711
In legacy, when you have a label with a string attribute that is empty,
that label is rendered as empty. In the new form view, when the string
attribute was empty we would fall back to the default label for that
field, which is incorrect.
This commit fixes that by not rendering labels that have an empty string
at all.
closesodoo/odoo#98237
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
There were 2 problems before this commit:
1. When switching view and coming back from the breadcrumbs: the
previous view props (such as the pager props) were lost;
2. When paging to the next record, switching view and coming back from
the breadcrumb, the view was reverted to the first selected record,
effectively ignoring the paging step.
This commit fixes both of these issues by keeping the controller's
props during a "restore" action, and by also updating the current
controller's props when using the pager.
closesodoo/odoo#97395
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Inside a res.config.settings form view have a label with a string on it placed
before the field it is linked to.
i.e.:
```
<label for="myField" string="myString" />
<field name="myField" />
````
Before this commit, the string was not taken into account to build the HTML label.
After this commit, it is.
closesodoo/odoo#98109
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
*: mail, web.
The pyEnv used during tests is based on the mock server to provide
server like api. This issue is that when creating multiple environments
during tests, a new mock server is created each time. This is not realistic
since in a real world scenario, multiple tabs would share a single server.
In order to make pyEnv work with multiple tabs tests (e.g. multiple env tests),
let's create a single mock server shared between js environment during a test.
task-2053917
Part-of: odoo/odoo#97975
Spawn a form view with a record and set its props "mode" to readonly.
Click on "Create".
Before this commit, the new record was in readonly mode.
This is never what we want, we always want a new record to open
in edit mode.
After this commit, the new record is in edit mode.
closesodoo/odoo#97451
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
The mock of sendone/many was relying on the bus_service. Since owl.Component.env
is changing during tests setup, the bus_service was not always defined. In order
to make this more reliable, the longpolling/poll route is now mocked, returning a
promise that can be resolved by the sendone/many methods.
closesodoo/odoo#97298
Related: odoo/enterprise#30059
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On the res.config.settings form view, click on button that will do an action
e.g. defined as some flavor of `<button type="object" name="myMethod" />`
Before this commit, this did not work as we never fully created the res.config.settings record in python
hence, when executing myMethod on the model res.config.settings, the ID was unset, pointing to no record.
After this commit, we "create" in python the transient res.config.settings record before doing anything.
closesodoo/odoo#97428
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Jorge Pinna Puissant