**Issue:**
When a copy clipboard field is empty, there is no way to edit it
because the Field component is not shown.
This issue can be reproduced using any type of copy clipboard field:
- CopyClipboardChar
- CopyClipboardText
- CopyClipboardURL
Check the following video for illustration:
https://youtu.be/CTzqJRtwqv0
**Solution:**
This PR proposes a fix of *always* showing the copy clipboard field
(together with the copy button) even if the content is empty.
For illustration, check: https://youtu.be/jMM7zn_mFCU
**Notable changes:**
- The modified tests were using a wrong class name. But since they were
asserting the "non-existence" of the copy button, they were working.
- We are casting null text field to empty string (just like char field)
so that we avoid crash (in dev mode) when passing a "boolean" as 'content'
props to the 'CopyButton' component. This is asserted in the augmented
test case where we also try to render an empty text field.
closesodoo/odoo#104248
Task-id: 2861388
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Even if a many2many field is forcely set to be sortable, it should
not be included in the list of custom groupby options if it's
an un-stored field.
closesodoo/odoo#104978
X-original-commit: 9ba52387481bb0720c5d4f5d8a86c3ad6e801137
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:** The aggregate row of the list renderer doesn't take into
account the fields with zero values. As a result, average values are
not correctly computed. E.g. average of [2, 0] => 2 instead of 1.
**Solution:** Make sure 0s are included in the valid values to
aggregate.
**Change note:** We took the opportunity to make a simple refactor
in the affected test. Instead of asserting contents of the row
with multiple strictEquals (one per cell), we use deepEqual to
check the cells in the aggregate row.
closesodoo/odoo#104968
X-original-commit: 2dcb71aab911a47d8d3a5db6f68a28d1c6d8c9fb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps:
- Open studio in any form view
- Add Binary Field
- Close Studio
- Upload a file in the previously added binary field
- We can't download it because of always edit
This commit adds a new download button near edit and clear button
opw-3028094
closesodoo/odoo#104961
X-original-commit: 73a2329b8bf4e887890cae7669bc568ae0be7147
Signed-off-by: Luca Vitali <luvi@odoo.com>
Custom grouping by m2m field is introduced here: https://github.com/odoo/odoo/pull/74985.
However, after refactoring in https://github.com/odoo/odoo/pull/73311,
users are unable to add custom groups based on stored m2m fields.
This is because the stored m2m fields are not included in the list of
"Add Custom Group" options.
In this commit, we are now again including the stored m2m in the options
for "Add Custom Group".
closesodoo/odoo#104873
Task-id: 3046183
X-original-commit: 5087d9011be7f46a4a3e05b1e951f2556f254b4c
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, accessing parent in a button context broke the button
throwing `EvaluationError: Name 'parent' is not defined`.
to fix,the proxy object `params.evalContext` was passed to `evaluateExpr`
similar to examples seen in `list_renderer.js`
closesodoo/odoo#102293
X-original-commit: 90afb529969ce7de83a20060f5c35a64ce4cf971
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
The Race concurrency promise never settles if the first settled promise
rejects and therefore you can't catch the rejected promise.
closesodoo/odoo#104733
X-original-commit: 24cc8cdb440a5af944d82a25d98b0239e72e2625
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
**Issue:**
When a group contains more than 10k items, its pager only shows
10k as limit, even if the group already knows it's total count.
**Solution:**
We now allow creation of `DynamicRecordList` with 'countLimit' as
one of the params. It will be used in the instantiation of the
class but will default to WEB_SEARCH_READ_COUNT_LIMIT if not
provided. This way, pager's limit will be properly set to the
group's count.
closesodoo/odoo#104698
X-original-commit: 4751f85ac9d430528106de05bcdc484ae0c7079b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In the PR #97692, writing empty str `''` to a model term field no longer removes
all translations. Instead, only the translation for the current language is set
to empty str `''`.
Before this fix, if a web user sets a translation to emtpy str, and reopens
the translation dialog, the translation will be reverted to the 'en_US' value
which is wrong.
closesodoo/odoo#104181
X-original-commit: f97ff6308d472121e65a34d30b4dc5ab35065220
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
As of now, if a user clicks on the "Save & New" button while the form is
not valid, it will disable all buttons without any options to make them
enabled again. The only solution then is to close the form and re-open
it.
Steps to reproduce:
Inventory -> Configuration -> Route -> Select any route -> Add a line to
the rules.
As soon as you click on the "Save & New" button and the form isn't
valid, you can't use any buttons anymore.
Part of task-2985735
closesodoo/odoo#102315
X-original-commit: 6d63d1035b28f2004774a99a7be84b92a1cb1883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, in the list view, clicking on the "export all"
button created an xslx file that did not reproduce the order of the
columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the
columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the
order in the list view.
After this commit:
The order of the columns in the created file is the same as in the
list view.
closesodoo/odoo#104541
X-original-commit: 734eee368d548fddc6c516ff559d09e853d1ab74
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit, if a translation dialog was open, and the view where
the button is unmounted, the dialog stays open.
Now, the dialog closes, when the view is unmounted.
closesodoo/odoo#104543
X-original-commit: 40596ed1eccdf0f37b4fa3a8a337e7a7cc3461ce
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
"div" as a child of "tr" is not really allowed. Because of this,
custom widgets in a list_renderer are not properly styled resulting
to issue where a widget doesn't take the full height of the
parent "tr" element.
This was missed during initial wowl porting so in this commit,
we are putting the widget inside a "td" element.
closesodoo/odoo#104475
X-original-commit: 092b6b66d998795a03de82be4d33990a138396e1
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
removeContextUserInfo was a Spreadsheet asset, which is not a dependency of
Knowledge.
In order to make this feature available for all modules, it is moved in web as
an object util, that needs to be used alongside the user service in order to
dynamically remove user context information (no hardcoding).
Task-3017349
closesodoo/odoo#104304
X-original-commit: fd88fc1bbad4c0cdb44cf634b6a5621eb7597e0d
Related: odoo/enterprise#33322
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
ISSUE: When in debug mode, user have access to the "External
Identifiers" view. The search bar allows searching using "Record
ID" which is a `many2one_reference` field. When user inputs
a search query that can't be converted to number, "Record ID"
option is still available to the user. It results to traceback
when it's selected because the UI is creating an invalid "domain"
which makes the server search for a string on an integer
(many2one_reference) field.
Check the video for illustration: https://youtu.be/XEPUXHcjeRI
SOLUTION: We make sure that many2one_reference field is properly
converted when generating the domain from the search_bar by
using the integer parser. This basically excludes many2one_reference
field from the search options when the input query is not a valid
integer. See it in action: https://youtu.be/NQ-YrK6tDH0closesodoo/odoo#104183
Task-id: 3005837
X-original-commit: bc9e8709309379bdd9191323cb015c89be7da1f9
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps:
Go to timesheet (grid view).
Launch the timer.
Got to list view and check the new line.
Issue:
Few seconds before the minute, the seconds are negative.
Fix:
Convert hours decimals in milliseconds before calculating minutes and
seconds.
Also deleted the unnecessary condition for abs().
Also changes some `${...}` to String(...) to reduce noise.
closesodoo/odoo#104209
X-original-commit: 9d3e7ab4e903d2ada99693aa23e024d3ff84f5fb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the Datefield dropdown did not close when you
scrolled on the page.
How to reproduce:
- Go to a form view with a date field
- Click on the date field input (datepicker is opened)
- Scroll down the page
Before this commit:
The datepicker is still open
After this commit:
The datepicker is closed.
closesodoo/odoo#104160
X-original-commit: d93ed838fdf0a721426dc56e26b5a83b3af6a66f
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
The web client exposes an utility function that converts the tokens
of a luxon's DateTime format into a moment.js format.
While this function is not false (still it is uncomplete), the strategy
of using it to convert a luxon's DateTime object into a moment.js moment
is not good.
The daterange field make use of this bad strategy.
Because of the differences between luxon and moment.js locale handling.
Luxon relies on the native JavaScript Intl API.
Moment has its own implementation of locale handling.
So having to pass through formatters/parsers may yield to unexpected
results. For instance, when a locale does not have the same way (in
moment.js and Intl) to express i.e. months and we try to convert a
luxon's DateTime into a moment by formatting the first and then
parsing into the second, the second will be invalid. This is the same
the other way around.
This was in fact encountered with some locales, i.e.
- syrian arabic (ar-SY)
- albanian shqip (sq-AL)
This commit brings an alternative strategy by providing other utility
functions to directly convert a moment into a luxon's DateTime
and vice versa.
This is a better strategy for various reasons:
- it abstracts the way the conversions are done
- no need to play with timezone's offsets
- probably all libs that has moment as a dependency accept a moment
object in their options, that may not be the case for formats
- The daterange field now use the new strategy
- The datepicker component now use the new utility functions as it had
implemented locally something similar.
closesodoo/odoo#104138
X-original-commit: 9dedfcaa4ad1fb5ea24f604b40df1bf0830617cb
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This makes sure that the handler is properly assigned/removed
to/from the added/removed input elements.
closesodoo/odoo#104114
X-original-commit: d88b5e96a4d4a80dd14a271538a4669a6efd2d48
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When NumpadDecimal is triggered, appending the decimalPoint to the
input field value is not enough, rather, we should replace the selected
range.
Also, we should ignore this for input field of type="number" because
it's natively taken into account.
X-original-commit: 3389cd2226ec82df9aa015637ac2d6a405936a4a
Part-of: odoo/odoo#104114
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>
Before this commit, if an invalid list view is left, then a "View can't
be saved" error dialog is displayed.
The expected behaviour is a notification indicating the invalid fields.
How to reproduce:
- Go to a list view with at least one required field
- Create a new record
- Edit this record while leaving the required field empty
- Leave the view
Before this commit:
You stay on the view and get the "View can't be saved" error dialog.
After this commit:
You stay in the view and you get a notification "Invalid fields: "
with the invalid fields displayed.
closesodoo/odoo#104082
X-original-commit: 98fbacd8511594ca7a8cc9f0afa5d199a9b2ff20
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a multi_edit list view, if you click twice on
a readonly field, the focus is placed on the readonly field.
How to reproduce ?
- Go to a list view in multi_edit="true" mode with a readonly field
- Select a record
- Click on the readonly field of the selected record
- The record goes into edit mode and the focus is placed on the editable
field following the readonly field
- Click a second time on the readonly field of the selected record
Before this commit:
The focus is placed on the readonly field.
After this commit:
The focus is placed on the next editable field.
X-original-commit: aac7e6e4de371dcd01028a3a9ab66eed022c1ef0
Part-of: odoo/odoo#104070
In a kanban arch, have a dropdown that don't have a toggler, just an
explicit menu.
Before this commit, there was a crash.
After this commit, the kanban and the dropdown are correctly rendered.
closesodoo/odoo#104019
X-original-commit: 01418c474cb02455660156cf47822588f0554376
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a kanban arch with a field in display full in the kanban card template
```<field name="fieldName" display="full" />```
Before this commit, the class that should endup in the DOM was wrongly computed.
Technically, it was quoted in the owl template as if we passed it to a Component.
After this commit, a field having display="full" is correctly rendered.
X-original-commit: 526eb4f875ec6736d4b76da1fbdbcc99a8c33a9b
Part-of: odoo/odoo#104019
The goal of this commit is to restore the behaviour of the legacy
attach_document widget.
How to reproduce :
- clicking on the attach_document button and selecting a file
In legacy:
We have a full reload of the view (Render and reload the record).
Before this commit:
Render the view without reloading the record.
After this commit:
We reload the model which causes a rendering of the view and a reload of
the record.
Why do we have to reload the record ?
If the action linked to the attach_document button modifies the record,
we want this modification to be applied in the view and not only on the
server side. To do this, we need to reload the record data to ensure
that all the changes are displayed in the view.
closesodoo/odoo#103891
X-original-commit: 82d4f0cd2f0265393cf66cd7be1a0a714584400c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in a list view in multi_edit mode and editable="0",
it was possible to edit a required field with an invalid value.
Why:
In the PR 101924, we decided to no longer pass readonly/required of fields
in non-editable views (if no editable="1").
Solution:
To know if a view is editable, you should not only look if it is
editable="1" but also if it is multi_edit="1".
So we want to pass the readonly/required fields if the view is
editable="1" or multi_edit="1".
How to reproduce:
- Go to a multi_edit="1" and editable="0" list view with at least one
required field on the server side
- Select the checkbox of the record you want to edit
- Edit that field with an invalid value (e.g. clearing a text field)
- Click outside the line being edited
Before this commit:
The record is saved with the invalid value
After this commit:
An alert dialog is displayed to warn us that the value is invalid.
The record returns to readonly mode with the old value.
closesodoo/odoo#103790
Related: odoo/enterprise#33066
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
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>
Fix the hatching and striking effects for events
by moving some scss rules to the right place:
- o_event_hatched
- o_event_striked
Various fixes for the calendar popovers to display properly, such as:
- year scale popovers
- proper popover body padding and font-size
- style that depends on attendee status
- other scales popovers
- inverse the condition when the popover footer must shrink
closesodoo/odoo#103661
X-original-commit: 917d8e4123517c73d8bd6a4bd83becf1b0ee1090
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@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>
Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103579
X-original-commit: ee1a8d26f241f2f7bea6880afcc946119b0e6bd8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Now that the module web_dashboard has been removed https://github.com/odoo/enterprise/pull/31641,
some props of the reporting views graph and pivot have become unused.
We remove the code related to those props.
X-original-commit: 7d231d1d37707dab4b0ecdd4e2e7cc4535ba6196
Part-of: odoo/odoo#102761
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit removes the code that wrapped legacy fields and widgets
(coming from the legacy registries) into owl components and added
them to the wowl registries. This temporary compatibility layer,
which was incomplete and only allowed us to merge the new views
without converting all fields/widgets in once without breaking
everything, is no longer necessary as we now have converted all of
them into owl components.
X-original-commit: 555959c87e25faa71396f61479e8bb41b66ac164
Part-of: odoo/odoo#102606
Before, even if the checkbox is deactivated, clicking on it
cause an `onChange`.
This caused unexpected behavior, the form view changed to a dirty
mode even if the checkbox was in read-only mode and nothing
was modified.
Now, the checkbox does not call `onChange` when deactivated.
closesodoo/odoo#103429
X-original-commit: 4802c2528cfa23c5981fa30fa69cfa23f28faf05
Signed-off-by: Luca Vitali <luvi@odoo.com>
Have some keys in the context passed to a view.
Have a many2x field in that view that uses those keys in its domain
with some flavor of:
```xml
<tree>
<field name="many2one" domain="[['someField', '=', context.get('some_key')]]" />
</tree>
```
Before this commit, the global context was not added to the evalContext used to evaluate the domain.
After this commit, it is.
closesodoo/odoo#103370
X-original-commit: 93c5e6cbc06bdb6ab2cfc959b68be8088837e1de
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@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
Do an action in target new that will spawn a record in its form view.
The typical example is "Edit View: XXX" in the debug systray.
On the dialog, click on "Discard".
Before this commit, that button did not close the dialog.
After this commit, that "Discard" button closes the dialog.
closesodoo/odoo#103275
X-original-commit: 08751e0eef0cefe74e626ffa8ba26a5e8f18113f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the basicRelationalModel could not handle the legacy
event "reload" trigger by the basicModel., resulting in crashes.
In particular, when the method "action_archived", via the method `record.archive()` returns an action
(in target new usually) to confirm or ask the user for some additional information, closing that modal
will trigger a model reload via the event.
After this commit, this whole flow is tested and works correctly.
closesodoo/odoo#102826
X-original-commit: 0abb90fb2aa7857990b5f5dae95e9e891125b5fa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Joseph Caburnay