The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
QWeb views allowed to render QWeb templates rendered by the server in
a view.
Today, QWeb views are only used in website to see the hierarchy of
their views. The use case of website has now more sense in a client
action rather than an extension of a QWeb view.
This commit removes this view because it is not used anymore and will
probably not find any useful use case in the future.
closesodoo/odoo#103477
Related: odoo/upgrade#4016
Signed-off-by: Aaron Bohy (aab) <aab@odoo.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
Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore. Note that [1] was
actually not forward-ported here in 16.0 but now is via this fix.
E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).
Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working). This flow was
also not broken in 16.0 as the code was rewritten differently.
The work done at [1] actually needed some more rework than that to
handle two other potential usecases:
- If the confirm dialog handlers' promises are rejected, the dialog is
not closed (rightfully, like for example allowing to fill an empty
required input)... but [1] prevented to click on the button again
forever. With the same example as above, it can be reproduced: if the
RPC to clone the page fails, I cannot retry.
- If not both confirm_callback and cancel_callback were given, [1] only
prevented to multi-click on the related button (e.g. if you click on
"Ok", a RPC which takes 10 seconds is made, you click on cancel
immediately afterwards -> the dialog is closed while it should be
prevented (and would be if cancel_callback was given, following [1])).
That may not be entirely stable to make this change though but it
seems to make sense and be better (just keeping what [1] wanted here).
Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).
[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b
Closes https://github.com/odoo/odoo/pull/103712
opw-3033878
opw-3043224
opw-3046485
opw-3042542
closesodoo/odoo#105081
X-original-commit: 90b280c221f3c0819cb0b291e102f161fc47507a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The calendar view and all its extensions have been converted to
owl, so it's time to get rid of the legacy implementation.
closesodoo/odoo#101816
X-original-commit: 681a6a98c9919021c2f688609e5e4263a9cf4d14
Related: odoo/enterprise#32130
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This field widget is no longer used in form, list or kanban views,
so it hasn't been converted to owl. This commit removes its legacy
implementation from the registry, s.t. we ensure nobody use it
again. Moreover, we adapted a new view test using it to use another
field widget instead, to remove the dependency and ease the removal
that should happen soon.
closesodoo/odoo#101787
X-original-commit: 68cfd4b08bc9ab0305ae9033e42820370b52bdf3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit renames the 'o_view_sample_data' class to
'o_legacy_view_sample_data' in legacy views to allow new views to use
different sets of rules.
X-original-commit: 05ae053dc94f9ce91c099d74f6740604e3e376c3
Part-of: odoo/odoo#101485
This commit introduces the new calendar view written in owl.
closesodoo/odoo#101185
X-original-commit: e88988f58582d5b49a32d7102a74a176f40c4c69
Related: odoo/enterprise#31808
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Now that web_studio no longer uses the legacy graph and pivot views and
that all their extensions have been converted, we can finally remove
them from the code base.
closesodoo/odoo#99734
Related: odoo/enterprise#31112
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
Before this revision,
it wasn't possible, in the form header,
to organize buttons in nodes.
If you attempted to do so, the buttons were not appearing.
e.g. for the below form
```xml
<form>
<header>
<button name="0"/>
<button name="1"/>
<div id="special_buttons">
<button name="2"/>
<button name="3"/>
</div>
</header>
</form>
```
Before this revision, the buttons 2 and 3 were not appearing.
Adding this possibility can allow simpler inheritage,
for instance by organizing buttons in sections and then
the inherited view can add buttons directly within the right section,
using a selector targetting the section.
It also allows to restrict a button to users having 2 groups.
e.g.
```xml
<button name="action_draft" position="after">
<div groups="sale.group_auto_done_setting">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</div>
</button>
```
If you want to restrict the button `action_done` to users
having both `sale.group_auto_done_setting` and `sales_team.group_sale_manager`,
you cannot put both groups on the same node,
because otherwise it's an OR connection, not an AND.
`groups="sale.group_auto_done_setting,sales_team.group_sale_manager"`
means
"users has `sale.group_auto_done_setting` or `sales_team.group_sale_manager`",
not AND.
So, the only possibility to restrict a button to two groups with an AND
connection is to restrict the button to a group and nest the button
inside a block restricted to the second group.
The above example is an actual example/need from the existing code.
But, as this possibility wasn't there before this revision,
they achieved the goal by using the `groups_id` feature:
```xml
<record id="view_sales_order_auto_done_setting" model="ir.ui.view">
<field name="name">sale.order.form</field>
<field name="model">sale.order</field>
<field name="inherit_id" ref="sale.view_order_form"/>
<field name="groups_id" eval="[(4, ref('sale.group_auto_done_setting'))]"/>
<field name="arch" type="xml">
<button name="action_draft" position="after">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</button>
</field>
</record>
```
So they had to use an inerited view for that purpose only to restrict
the button to two groups. It's a work-around.
It is much simpler to allow to have nested buttons in the header of the
form.
closesodoo/odoo#98551
Related: odoo/enterprise#30643
Related: odoo/upgrade#3812
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
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>
- 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
Vincent Schippefilt