- Purpose
Improve the UX of the "column creation" mechanism in the kanban view
so that users better understand what it is they are creating.
- Specifications
In the kanban creation mechanism, use the name of field on the model
(e.g. when grouped by stage_id in project.tasks kanban, "Add a Column"
would become "Add a Stage" because the stage_id field's name is "Stage").
task-2755570
closesodoo/odoo#95550
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit simplifies the component SCSS improving bootstrap
integration and allowing components other than 'SearchPanel' to use the
same tree-view design.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2795166
closesodoo/odoo#87687
Related: odoo/enterprise#25781
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
In BS5 there is a check to avoid having multiple handler for one
element and we can't add two components' instance on an element.
So, before disposing a tooltip we check if there is an instance of a
tooltip and we avoid instantiation of tooltip if not already done.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.collapse.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.carousel.
> Bootstrap doesn't allow more than one instance per element.
> Bound instance: bs.tooltip.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
* data('bs.popover') is not a jQuery data anymore
-> fetch data from the instance instead.
* use the new class name 'popover-arrow' instead of 'arrow'
* website_forum: offset is not a number anymore
-> Convert to string instead.
* BS5 event listener: 'focus' -> 'focusin'
* use `mouseover` event to show and `mouseout` to hide.
* disable at some point the animation to avoid remaining listener
in the DOM.
Ref:
https://getbootstrap.com/docs/5.1/migration/#popovers
Task ID: 2766483
Part-of: odoo/odoo#95450
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
action act_window can have a "flags" field which contains tweaking parameter for the views.
A little inventory:
- ation_buttons: if true displays on List and Kanban the buttons that trigger action
in the control-panel bottom left area. It is true by default in JS.
- withControlPanel: whether to display the ControlPanel as a whole. True by default.
- search_view: not used or dealt with.
- mode ("readonly"|"edit") whether to initiate a form view in that mode.
(used and practical -- but will be outdated when the edit mode by default is implemented)
This commit removes the occurences of those flags keys that are useless
closesodoo/odoo#94078
Related: odoo/enterprise#28620
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
It is very common when using kanban view to need a way to declare what
action is executed when clicking on a record. The default action
(switching to form view) is sometimes not what we would like. For
example, clicking on a project kanban record should open the
corresponding tasks, instead of the project form view.
Until this commit, it was not possible to do this simply for a whole
kanban record, however it was possible to add a button with a name and
type attribute to specify the resulting action. This commit introduces
the same idea, but on the complete kanban record, instead of just a sub
element.
To specify the action that should be executed when clicking on a record,
one can now use the 2 attributes 'action' and 'type' (which corresponds
to the 'name' and 'type' attribute for the kanban record. 'name' was
also considered, but it was too weird). For example:
<kanban default_order="name" action="action_brand_model" type="object">
...
</kanban>
Part-of: odoo/odoo#92071
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing assertion
(specifically in the list view column sizing tests).
As the difference is *really* small, introducing a margin of error (i.e.
<= 1px) looks reasonnable ; as implemented in this commit.
closesodoo/odoo#92203
Forward-port-of: odoo/odoo#92066
X-original-commit: 5f0353814fc314b75a34a38e700bd7f0797dd18d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Instead of having 4 buttons to select a view in calendar, we start using a
dropdown button with the framework data-hotkey approach.
task-2704432
closesodoo/odoo#81705
Related: odoo/enterprise#23131
Signed-off-by: Arnaud Joset <arj@odoo.com>
Prior to this commit:
- If the color attribute is set on a field on which the user might
not have access to the model / record, a traceback is returned. However,
in the case of a M2O, the name_get would be returned, so its is
a pity that the color raise an access error.
After this commit:
- A search_read is made instead of a read, which returns nothing if
the user does not have access to the model / record and does not raise
a traceback.
closesodoo/odoo#91147
X-original-commit: 3e8744418d629a62e9eacd16dfa4721921e02453
Related: odoo/enterprise#27318
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, when we go to the planning > config > resource
(editable list view without any record) and create a ersaource
the color picker widget is resized vertically instead of horizontally.
In this commit we have fixed the issue, when there is no record in
the planning_resources list view, the color_picker widget gets 72px width by
default, so we have added a condition that if there is a color_picker widget
in a field, we will calculate the width based on the total fields in the view.
task-2720976
X-original-commit: d047080c18ea4c9314df5f2aefdfb6b7deeef45a
Part-of: odoo/odoo#90897
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
When having a subview for a 2many field, if an onchange is triggered for
that field, the default values of the parent are still in the request
context.
To reproduce the issue:
(Need helpdesk_repair. Use demo data)
1. Helpdesk > Configuration > Helpdesk Teams, edit "Customer Care":
- Enable "Repairs"
2. Create a storable and tracked-by-usn product P
3. Update the on-hand quantity:
- 1 x P with serial S
4. Helpdesk > Customer Care (Tickets), create a ticket:
- Product: P
- Lot/Serial number: S
5. Click on Repair and save the repair order R
6. Edit R and add a line in "Parts"
Error: on the new line, both Product and Lot/Serial fields are already
filled with values P and S, which does not make sens
On step 5, when clicking on Repair, the form views of a repair order is
loaded with a specific context:
https://github.com/odoo/enterprise/blob/deef3c967d43862edf02dbcfc461fb89b064731e/helpdesk_repair/views/helpdesk_views.xml#L31-L34
Therefore, when editing the form and trying to add a new line in Parts,
an onchange is triggered but the default values are not removed from the
context. As a result, since the model `repair.line` also has two fields
called `product_id` and `lot_id`, the default values of the parent
(`repair.order`) are used.
When computing the context of a subview, the default values of the
parent should be removed.
OPW-2752436
closesodoo/odoo#89366
X-original-commit: db7423a97fd812fe6df95296fd7a6ca18854933b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to follow
- Go to Accounting > Accounting > Sales (account.move.line model)
- Remove any existing group by
- Group by Products
- Select multiples lines of the same product
- Try to modify the account of the select line
-> `this.localData[value] is undefined
Cause of the issue
When grouping by a field not in the view, `list.__data` contains the
groupedBy field value because we fetched the group through a web_read_group
Solution
Filter out absent fields before creating the group datapoint
opw-2784995
closesodoo/odoo#88634
X-original-commit: d65852352ee4163f7097c19ac3c4a479922f32b8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, clicking on a x2m field when form view is not
editable (edit=0) did not open the dialog to show the related record.
After this commit, the dialog opens when clicking in a x2m field
of a non editable form view.
closesodoo/odoo#88378
X-original-commit: 80acf449bcaf5ff3d2ba81d84efc0498bc78c533
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Steps to reproduce:
- Install accounting
- Create more than 6 analytical tags
- Create an invoice
- Create a payment
- Go in Accounting>Actions>Reconciliation, tab Manal Operations
- In the field Analytical Tag, click on 'Search More' and selected 1 or multiple tags
Issue:
Void tags are displayed
Solution:
Fetch the field `display_name`
ref commit: 84f0644802865c6454014059842eb6a9d4fd40e4
opw-2734029
closesodoo/odoo#87311
X-original-commit: 936bad32cf1024570da4880ccc5375b02b30c1c2
Related: odoo/enterprise#25631
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps :
Install Sale / E-commerce.
Create product P (price = 100).
Create price list L aka product_pricelist.
Create price rule R (product = P, price = 50) aka product_pricelist_item.
Go to product P > Price Rules > archive R.
Issue :
This should not be possible, as product_pricelist_item.active is a
readonly field (related to pricelist_id.active).
Fix :
Make BasicView.controller.archiveEnabled depend on that.
opw-2752184
closesodoo/odoo#86018
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
Part-of: odoo/odoo#85651
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
Some tests are updated to have less LegacyComponent.
Part-of: odoo/odoo#85389
*: mail, mrp
Previously, to prevent images and iframes from making GET requests in
tests, we would listen for the DOMNodeInserted event. This event is
deprecated and should not be used. Additionally, we weren't listening
for attiribute changes for performance reasons, which would result in
some GET requests still being made when an src attribute was changed.
This commit changes the mechanism that is used to do this from mutation
events to a MutationObserver which is not deprecated, and now also
listens for attribute modifications as MutationObservers can be
configured to only listen for changes to certain attributes, greatly
alleviating the performance impact of listening for those.
This mechanism has also been enabled globally by doing it once in the
test setup code, instead of requiring one to call a specific helper, as
we never want to make real requests during tests.
Some tests have been adapted to this new behaviour.
closesodoo/odoo#85216
Related: odoo/enterprise#24665
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
When we group the record based on a boolean fields, we want to show
"Yes/No" instead of "True/False".
This has been done for the list view, the pivot view and the kanban
view.
Task-2648390
Part-of: odoo/odoo#79911
This is not a big deal, but by passing a widget instance or a DOM
node as message to a QUnit.assert function, QUnit keeps a reference
to that instance or DOM element, and it can never be garbage
collected (nor its bound handlers in the case of a DOM element).
For the mail case, this was a bit more critical as we didn't check
what the author of the test actually wanted to check.
closesodoo/odoo#83384
X-original-commit: 692fd6ecee602f7ceaae093b855aff65d50ca797
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a line chart in comparison mode with one groupby,
if only data comming from the comparison period were displayed, the line
(with red border) would be filled incorrectly with a blue color while it
was not supposed to be filled at all (the blue filling is supposed to be
reserved to data comming from the reference period).
closesodoo/odoo#82577
Forward-port-of: https://github.com/odoo/odoo/commit/6747d982a56af0525cf52732c43351081831d32f
X-original-commit: 519e205a4b34fdecfe6b938ff4a6e93a02c2bda2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the graph view in line mode, fake data are added when there is few
data to center the graph (the points in facts). Now, there
are two problems with the relabelling of the labels created along with the
fake data:
- the relabelling (when it works) gives "Total" instead of "" (nothing)
- the relabelling crashes when the line chart is grouped by a date
field, a comparison is done on that field and no data is received.
We fix the problem by introducing a custom label similar to NO_DATA
(a custom label used to manipulate fake data in the pie charts).
Forward-port-of: https://github.com/odoo/odoo/commit/a30669d1ff258e3ac71dff4d78ca295aa1be2ec8
X-original-commit: 6374618e4d201a53182c6adf2127b0e64b4e48d1
Part-of: odoo/odoo#82577
Previously, RPCs would always receive the user-context as an extra
keyword argument if they had any keyword arguments themselves. When
creating the translation layer between the old API and the new RPC
service, this was overlooked, resulting in all legacy RPCs losing their
user-context unless the user context was explicitly passed. This commit
fixes that.
closesodoo/odoo#82530
X-original-commit: d959638e23a92cf880049a760c42da33e5908f41
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
kanban click on time value does not open the form view.
After this commit:
kanban click on time value will open the form view.
Task-2655411
closesodoo/odoo#82191
X-original-commit: 33b5e71aecc43b373ab7c863e1a1fe7a7dc8f7cb
Related: odoo/enterprise#23232
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit fixes the calendar test "select events and discard create"
which was crashing certainly because the event we want to click on was
out of the screen at this moment.
Calendar tests use positional mouse[down|up] events to simulate clicks
on events so we need first to scroll to the wanted event before clicking
on it.
closesodoo/odoo#82132
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.
closesodoo/odoo#81726
X-original-commit: 75bbec4f7fe14aa9d9c310ffcbd500bd1f70b14f
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Avoid displaying a traceback when editing a partner in form view.
This was observed in crm -> Sales Teams -> Clicking on a member to save
and pressing "save" (which returned a javascript traceback in master).
The same error was also observed in mass_mailing, when editing the
responsible of a mailing list.
This was due to the ev parameter being undefined in method _reset.
A simple check has been added to see if the event is defined.
Task-2694067
closesodoo/odoo#80504
X-original-commit: 88044fa003b3f17d2003bffb810965854427cbd3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Before this commit, when comparing a period P of reference to another one,
some rows with only data comming from P would not always be presented
in the table. The problem used to manifest only when loading at least to
level at the same time (starting from Total or any header via expand all).
The reason is the following:
- the data comming from P are processed first: starting from somewhere
in the trees of headers, some nodes linked to the data comming from P
are progressively created with no children at first, then the children
(if any) are added later and so on progressively.
- the data comming from the other period is processed and nodes are
created with no children and so on in the same way, clearing possibly
all the node children comming from P.
For example, with
a row groupby = [field_a, field_b],
a group [v, v1] from P
a group [v, v2] from the other period,
a node corresponding to v would be added, then a node child for v1.
Then the node for v would be recreated with no children, then a node child
for v2 would be created. leading to a tree of row headers of the form
Total > v > v2.
Note that it was not affecting the measure values for the displayed rows
since those measures are stored separately from the tree and are linked
to the nodes via some ids.
We fix the problem by avoiding the recreation of a node if it already
exists.
opw-2635113
closesodoo/odoo#80468
X-original-commit: 364475b5da3d4aaa87db715f0c0bbaa9dd3e05c8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>
Steps to follow
- Go to the purchase app
- Create a RFQ, add a line, confirm it, lock it and save it
- Click on the one2many line
-> An editable popup is opened and the main form is also switched in edit mode
Solution
- Check if the one2many list has a readonly modifier before switching the main
form to edit mode
- When opening the one2many preview popup, pass along an editable param
opw-2689420
closesodoo/odoo#80338
X-original-commit: d1c9265659572c738596889f7a5ad53f673e9db4
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, the opening of a calendar popover could crash
because we tried to evaluate the domain of the readonly modifier.
Only the invisible modifier is necessary in the calendar popover so
this commit fixes the issue by evaluating only the invisible modifier.
It was also evaluated twice to do both the same thing so this commit
remove the duplicated lines.
closesodoo/odoo#80318
X-original-commit: c558ae309ff63a26c30ea0196930eb15a279e1dc
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit fixes some issues happening when scrolling
with an anchor in Odoo. When the anchor was contained inside
of a notebook and no scrollable was found, a crash happens.
This fix improves the behavior in notebooks by showing the
correct pane before scrolling in form renderer. The scrollTo
util has been improved to remove duplicate lines and handle
multiple situations (0, one or more scrollables). Tests haven
been written to test such behaviors.
closesodoo/odoo#79935
X-original-commit: 4c2b807d1cb32e52a1b1fb5e6c80fb7e933940bc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to follow
Edit the account.move view (with studio for example)
Set the lines readonly property to [["partner_id","=",False]]
Create a new move
Add a partner
Add a product
Remove the partner
-> A traceback appears: widget.$el is undefined
Cause of the issue
widget.$el is used after the widget has been destroyed
The fix was already present in 14.0 (3fd7b2009e)
but we still need to keep the test
opw-2557142
closesodoo/odoo#79261
X-original-commit: 71e6d7e510ff9d44fe8deb16f29d50b021709074
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
A stat button set as disabled was used to just show some statistics
without an action on click. However, on tasks executed by the Form,
all the buttons would be temporarly set as disabled then set back to
enabled. This would lose the original state of the button and make them
all clickable.
The way it worked before v14.5 was most likely because the action
manager would not throw an error on an action with those "invalid"
arguments.
Also, a button without a type and name will now be set the disabled
attribute automatically.
closesodoo/odoo#78839
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
stefanorigano (SRI)