Add two computed fields, `price_discounted` on `product.supplierinfo`
and `price_unit_discounted` on `purchase.order.line`, to get more
precise price.
For the vendor pricelist, it's useful to get the actual lower price (a
vendor price can be lower than another one but the result can be
different if the discount is take in account).
For the purchase order line, it's useful to get the right price in the
products catalog.
task-3373589
closesodoo/odoo#135502
Related: odoo/upgrade#5223
Related: odoo/enterprise#48375
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit makes two major things:
1. Move the product catalog from `sale` to `product`.
It moves the product catalog's code from `sale` to `product` module in
order to be able to use it in other modules.
A mixin, `product.catalog.mixin`, was created for to make other models
catalog compatible.
2. It enables the product's catalog in `purchase`.
In `purchase`, the catalog differs a little bit from `sale`:
- If Unit of Measure is enable, the UoM for each product will appear in
the catalog;
- If the product purchase's UoM or the purchase order line's UoM is
different than the default product's UoM, the former one will be
displayed (in bold so the user can know it's the UoM to refer);
- When opening the product's catalog from a purchase order, the products
will be filtered by the PO's vendor;
- Some data from the vendor list will be used if appliant: the minimum
quantity and the price;
- If there is at least one product's packaging, a button will be
displayed to increase the qty by the packaging's one. If a packaging
is set on the purchase order line, this one will be used.
task-3373589
Part-of: odoo/odoo#135502
Purpose:
-------
Commit [1] added the properties field on the product.product template.
However, the product.template model is more suitable to hold these
properties as the product.product model already has attributes which
are quite similar to properties.
Task-3570286
[1]: https://github.com/odoo/odoo/commit/70043822103638f651a521bd2da36cfdfd86245eclosesodoo/odoo#139702
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, users who want to change the visibility of product's
documents need to open their form view and edit it.
The selection widget now allows users to quickly edit the way a document
is displayed to their customers from the product's documents kanban view.
Part-of: odoo/odoo#137975
Before this commit, the "Print Labels" button shows for all products except
services.
However, this button does not make sense for event_booth, event_ticket, course,
... products
So we only show this button for storable, consumable and combo products.
Task-3390587
closesodoo/odoo#136753
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The default behavior of report_action() is to check if the currently
selected company has their document layout configured. The product
labels do NOT depend on this layout at all though, so let's make it so
the configuration never pops up when product/lot labels are being
printed.
Discovered during task: 3046178
Part-of: odoo/odoo#126791
In previous versions (v14 and earlier) there was only 1 PDF product
label that was easily customizable by users. Then we became super
fancy and created 5 PDF product label formats that are called via 2
different report actions.
Unfortunately we were too fancy and the design of the new reports was
incompatible with user customization. To remedy this, this commit:
- makes it so you can actually open the report label in studio (i.e.
`_prepare_data` in `product_label_report.py` adjusted to handle studio
case + hardcode some values that used to be required from the
`product.label.layout` wizard)
- splits out the non-dymo labels into separate report actions so they
can be individually customized more easily (i.e. individually loaded
from studio)
- splits out the show 4x12 price/no price templates so they can be
separately modified without unintentionally affecting the other
Note that we expect users to be OK with:
- the barcode auto-magic (i.e. clicking on the barcode within the label
will NOT be product.barcode as some of them may expect) since we still
want to cover the use case of SN/lots printing instead of the product
barcode for pickings
- the user will take responsibility if they overlap/delete the
`extra_html` layout wizard value from the label (since it's not
visible in studio without lots of clicking)
Task: 3046178 - split product label templates
Upgrade PR: odoo/upgrade#5298
Part-of: odoo/odoo#126791
*: website_sale, sale_product_configurator
With this commit, Image options for the color variant have been
implemented. Now, users can use images to represent pattern colors such
as "leopard" instead of solely selecting a solid color.
- User can add, remove or change the color attribute value image from
the backend. If no image has been uploaded, it will use the
corresponding HEX color to represent color/patterns.
task-3381738
Part-of: odoo/odoo#132685
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose:
--------
This commit adds properties (and related properties definitions) on the
following models:
- hr.employee (hr.department)
- hr_recruitment.hr_applicant (hr_recruitment.hr_job)
- product.product (product.category)
- stock.picking (stock.picking_type)
These have been added to the related form, kanban and calendar views when
applicable.
Properties have also been added to kanban and calendar views of
- crm.lead
- event.event
- project.task
(Properties had already been added on these models and form views)
Task-3458627
Part-of: odoo/odoo#132578
The following summary view of the record in the activity views have been
improved:
- project_task: task state added
- project_project: project manager added
- event_event: responsible and the dates (date_begin_located and
date_end_located) added
- account_move: total amount, customer and state added
- sale_order: total amount and the state added
- purchase_order: total amount and the state added
- crm_lead: customer and stage added
- hr_applicant (hr_recruitment): recruiter added
- survey_survey: responsible added
- maintenance.request: added equipment and responsible
- stock.picking: added scheduled_date
- repair.order: responsible, schedule_date and product_id added
- mrp.production: added responsible
- hr_leave (hr_holidays): status is added and default deadline modified see
below
Ensures that "Schedule activity" is in one line by adding a colspan.
hr_leave activity: When a time off approval activity is created as a
consequence of the creation of a hr.leave, the deadline of the activity is set
to the date_from of the hr.leave minus activity type delay_count (default 15)
except if it leads to a date anterior to today. In that case it is set to
today. That way, in the activity view, the time off approval activities are
more or less sorted by related hr.leave date_from and the cell date is an
indication of when the time off is planned.
Technical note: on most activity view, the activity record was not occupying
all the horizontal space. To solve that problem the css has been modified and
the max-width (200) that was imposed on the sub div has been removed. And as
it was impossible to impose a max-width for a flex div (which is the common
case for the activity record), the max width is imposed on each text that might
be too long using the class o_text_block. That class has been modified to
impose a max-width. That's why that class has been added in most view.
Alternativly, we could have modified the activity compiler to add that class
when the attribute full was set (not done because not sure of the consequence).
Task-3300854
Part-of: odoo/odoo#138135
Before this commit, the `Sales` page is always visible in product
form view when `point_of_sale` and/or `sale` modules are installed
even if the product cannot be sold.
The reason is because the initial condition contained in
`attrs="{'invisible': ...}"` for that page has been completely removed
since the recent changes to remove `attrs` attribute and allow having
python condition inside `invisible`, `readonly` and `required` attributes
(instead of having only True or False as value for those attributes).
This commit reviews the visibility condition for that page to completely
hide that page in product module as it is currently the case but it also
adds the condition we had in attrs. That is, in product module, the
invisible attribute for that page will be equal to `1 or not sale_ok`
(and so always invisible thanks to `1 or ...`) and when `sales` or
`point_of_sale` modules will be installed then `1 or ` will be removed
to just keep `not sale_ok` inside `invisible` attribute.
task-3506730
closesodoo/odoo#135840
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when purchase app (or account) is installed,
the `purchase` page in product form view is always visible even
if the product displayed in the form view cannot be purchased.
The reason is when `attrs` has been removed and replaced by python
condition inside `readonly`, `required` and `invisible` attributes,
since the purchase page had `attrs="{'invisible': ...}"` and
`invisible="1"` defined in its attributes, the condition in `attrs`
has completely removed when the `attrs` has been deleted.
This commit fixes the issue by updating the initial invisible defined
in product module to have `invisible="1 or not purchase_ok"` to keep
the condition that was initially defined in `attrs`.
In purchase and account module, instead of replacing `invisible="1"`
by `invisible="0"`, we will just remove `1 or` to show the purchase
page only if `not purchase_ok` as it was the case before.
task-3506730
Part-of: odoo/odoo#135840
This will make it consistent with items applying to templates and
with form view where internal reference is shown.
It doesn't look like there is any reason to not displaying it in variants.
closesodoo/odoo#138866
X-original-commit: 9f53b8d2185a1abf9635c9d9f6c5378943da4d0a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Following 116879e17e81657f48a7d11780d8d30715ecc68f a few improvements were needed to make it more
complete.
task-3484125
closesodoo/odoo#137522
Related: odoo/enterprise#48563
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
before this commit, on printing product labels there
is no option to select the price list, always the
printed price is the default product price
after this commit, in the label printing wizard
the price list field is introduced and user can
select the price list before printing the labels
closesodoo/odoo#137190
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
before this commit, if the entered attribute combination in
template is creating more than 1000 product, the operation
is prevented by raising UserError.
as of now, there is no option to increase or decrease the
limit if user need to do so.
system parameter: product.dynamic_variant_limit
after this commit, if user needs to increase or decrease
the limit, it can be done by adding a system parameter
and set the needed value
closesodoo/odoo#137783
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This reverts commit 3b9401c354.
It shouldn't have been merged in the first place. The PR was `r-` but it
seems like the mergebot bugged and still merged it because there was an
occurence of `r+` in the sentence which asked robodoo to `r-`.
> robodoo r- just to be sure, since there was a random r+ not [...]
Rationale of the revert:
- Bad field name:
- "ecommerce" in product module
- "ecommerce" but used in POS
- Arguably very low value to share the field -> This field is used in
ecommerce to add info exactly between the price and the name of a
product. There is low chance that you want to share that exact
information with the POS.
- Technically, it couldn't work. What you design in website builder on
the product page is related to website assets JS and CSS, which are
not loaded neither in the backend and neither in the POS.
It was leading to multiple critical issues, mainly:
- Losing the whole style of the content (CSS)
- Breaking completly the snippets (visually and design wise) (CSS/JS)
- Not even show (JS is in charge of showing the content eg)
Note that the same issues were already existing in that field in the
backend (it's shown in the product form view). The ecommerce team was
looking for a solution to make it work, but it's impossible as to work,
it would need the website / frontend assets, which can't be loaded in
the backend / POS.
The cancel of this PR was validated with PO of POS and ecommerce
following those explanation, which they weren't aware of.
Apart from this revert, further PR will be done to:
1. Remove the field from the product form view (ecommerce app)
2. Create a new field for POS
Revert of https://github.com/odoo/odoo/pull/136906
task-3524272
closesodoo/odoo#137514
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit adds a popup to show product information when clicking on an
info button in the product card in the self order app. The popup shows
the ecommerce description and the name of the product.
The ecommerce description field has thus been moved from website_sale to
the product module so that the pos_self_order module can use it.
closesodoo/odoo#136906
Task-id: 3524272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When enable, this new feature adds the possibility to set a PDF header, footer and some product
documents to the quotation report.
These PDF can contains forms that'll then be filled using Odoo database.
This replace the previous sale quotation builder feature.
task-3249142
closesodoo/odoo#133773
Related: odoo/upgrade#5168
Related: odoo/documentation#5863
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Some clients use the same barcode for products in different companies,
with different configuration. It is inconvenient for those users to have
to ensure the uniqueness of barcodes across all companies.
This commit will allow products to have duplicated barcodes, as long as
they are assigned to different companies. Products without a company are
treated as belonging to all companies. Product variants require unique barcodes.
The validation needs to be triggered both on barcode and company_id, so
product template (where company_id is stored) was also adjusted.
NOTE: when a barcode is duplicated in 2 companies, an attempt to remove
both the company and the barcode from a product will result in an
error, despite the fact that a product without a company and a barcode
would have a correct configuration. This happens because the barcode
uniqueness check is performed before changing the barcode, but after
changing the company. A workaround for this problem is to remove the
barcode first, save the product, and remove the company.
Task: 3290154
Related task: 3270732
Related: odoo/enterprise#42541
Part-of: odoo/odoo#122511
[A previous
commit](https://github.com/odoo/odoo/commit/5ca1da8ab33d4dd6a9ed0b6737e5d19f1a3ac9d2)
introduces a new attribute `display_type`, `multi`, which allows users
to define extra-options to products. But this option was only available
in Sales.
This commit allows eCommerce users to use this new attribute in the
online shop.
task-3497046
closesodoo/odoo#135174
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
1) fix automatic creation of documents when attachments are added
to product templates/variants chatters
2) fix duplication of documents
3) fix deletion of documents
Delete child record before deleting parent record.
Before this commit, when trying to delete a product document,
we deleted the parent record first, before trying to delete
the child, which had been deleted (cascade) already.
Part-of: odoo/odoo#135894
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
This method & logic is not used nor necessary anymore with
the multi-company fixes and improvements done in the recent years.
* All requests coming from website are automatically done in the website
company.
* check_company restrictions forbid the use of records from different companies
* multi-company security rules restrict the access to records from the current
company.
Part-of: odoo/odoo#121986
Currently the user cannot modify the order as he adds new attribute to the product.
In this commit he will be able to do that
task-3451377
closesodoo/odoo#131514
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently there is no efficient way to suggest extra-options to
customers in PoS or eCommerce. Extra options should be easily selected
by customers (or PoS waiters) with checkbox. Each checked option would
add an extra-price to the product price and appear on tickets,
receipts, invoices, kitchen display, ...
This commit introduces a new type of attribute: multi-checkbox. This
will not create product variants. A default extra-cost is defined at the
attribute level, but it can be changed at the product level.
The new attribute is available in Sales, not yet in eCommerce nor in PoS
(it will be in a future task).
task-3256585
closesodoo/odoo#130915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
- Updates the product.product kanban view so that it matches
the product.template one.
- Fixes the favorite button
- hr_expense also requires the cost to be shown
task-3457035
closesodoo/odoo#131208
Signed-off-by: William André (wan) <wan@odoo.com>
__Current behavior before commit:__
`_get_own_attribute_exclusions()` returns the product template attribute
value (ptav) even when `ptav_active` is **false**. This makes the
frontend crash when we add a product that has such ptav to a sale
order.
__Description of the fix:__
Prevent ptavs with `ptav_active = false` to be in the result of
`_get_own_attribute_exclusions()`.
__To reproduce:__
1. Create new Product template
1. Add 2 attributes with at least 2 values each
1. Click on the Configure button next to the first attribute line
1. Click on the first attribute value
1. Add an exclusion line for the newly created product template and one
of the value from the other attribute
1. Put `ptav_active` of the ptav to `false` (not sure how to do it
except from the ORM but one customer managed to do it)
1. Try to add the product to a sale order line
1. `TypeError: Cannot set properties of undefined (setting 'excluded')`
opw-3466451
closesodoo/odoo#133808
X-original-commit: cf58369310f13377cd70794bf777f4e9198f643a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The product configurator can have irrelevant disabled options if the
product selected has some archived variants
Steps to reproduce:
1. Install Sales and Inventory
2. Create a product with two attributes, each with two values (e.g.
Color: C1, C2 and Weight: W1, W2)
3. Open one of the variant, add some stock then archive it
4. Delete the attribute Weight from the product
5. Create a SO for any customer and add the product
6. The product configurator dialog opens but the C1 color is unavailable
Solution:
Only return the archived combinations for which all of the attribute are
still used in the product
opw-3427753
closesodoo/odoo#132420
X-original-commit: d5cd215dcf1b7e633c86ad734274a65827368ade
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
before this commit, vendor product name and
vendor product code was not added in
vendor pricelists search view
after this commit, vendor product name
and vendor product code is added
closesodoo/odoo#129301
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Enable “Product packing” in the inventory settings
- Create a storable product “P1”
- Add a package with barcode “123”
- save the changes
- Delete the package
- Try to set the same barcode “123” for the product
Problem:
A validation error is triggered: "A packaging already uses the barcode"
Solution:
When we delete the package from the product, we have to delete
completely the “product.packaging" record.
opw-3378288
closesodoo/odoo#131825
X-original-commit: d01d8a9cedec2d1c17469538103340fc934470f1
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Louis (wil)