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
The motivation of this commit comes from breadcrumbs.
Breadcrumbs work as follows: for each controller in the stack of
the ActionService, there is an entry in the breadcrumbs. Except
for the last entry (which corresponds to the currently displayed
controller), the value to display is computed by the ActionService
and stored in this.env.config.breadcrumbs. For the last entry,
we use the displayName set in this.env.config.
When a view wants to update its displayName (e.g. the form view
when we switch to another record), it updates the displayName in
the config, which thus correctly updates the breadcrumbs. However,
this doesn't change the internal values in the ActionService, so if
another controller is stacked over the current one, the penultimate
entry is wrong. To update the internal state of the ActionService,
the event 'controller-title-updated' must be triggered as well,
which is cumbersome. Note that we don't really face the issue yet
because among already converted views, none of them need to update
its displayName in the breadcrumbs.
This commit aims at uniformizing the way the (n-1) first entries
and the last one behave, by making the "breadcrumbs" key encode
all breadcrumbs entries (the n-1 first ones, and the last, current
one). We also replace the "displayName" key by "getDisplayName"
such that it uses a single source of truth, located in the
ActionService, and we provide a function "setDisplayName" to update
it. Finally, this commit introduces the notion of "default config"
which ensures that standalone views, or views in tests, have a
valid config with expected keys.
closesodoo/odoo#81031
Related: odoo/enterprise#22799
Signed-off-by: Géry Debongnie <ged@odoo.com>
The purpose of this commit is to simplify the makeView api by removing
the noFields option.
Only two tests used it:
For the test "'resModel' must be passed as prop", the noFields option
was useless. So we can remove it.
For the test "'arch' cannot be passed as prop alone", it is not
necessary to use makeView. So we will replace it.
closesodoo/odoo#81119
Signed-off-by: Aaron Bohy (aab) <aab@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>
With this commit, we add percentage information in pie chart tooltip,
A pie chart is meant to illustrate numerical proportions.
In Odoo, when hovering a piece of a pie chart, the tooltip is currently not
displayed the proportion/percentage of the piece in the pie. The purpose of
this commit is to provide the user with the percentages of data distribution by
adding them in the tooltip.
In the tooltip displayed when hovering a piece of the pie chart, add the
percentage between brackets.
task-2608695
closesodoo/odoo#78343
X-original-commit: f73bd6dad71045d9f0a012259f148f0c768b964b
Signed-off-by: FrancoisGe <fge@odoo.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit rewrites the pivot view template to make use of the view
layout component.
X-original-commit: ebb046c5b9b6b629fd6731a419c5b7daf57a9f7d
Part-of: odoo/odoo#77463
This commit rewrites the graph view template to make use of the view
layout component.
It also removes a duplicate test in the graph test suite.
X-original-commit: a9a65fd51a2317adc07bf3742f7edc360236d32e
Part-of: odoo/odoo#77463
This commit introduces a new component: the layout component.
Its purpose is to make abstraction of most generic components and
classes when writing a view template or an action.
To make use of this component, we also needed a new system to pass slot
from the parent of the layout to the control panel. This was done in a
hacky way and is meant to be replaced as soon as Owl provides a built-in
way to pass slots.
The control panel has also been slightly tweaked to default its props
from an environment's newly introduced key: the 'config'. This has been
done to reduce the amount of props passed to the layout and search
subcomponents.
X-original-commit: 3b29dd230acd961a72fb0cb971f9363958f65b60
Part-of: odoo/odoo#77463
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The option was available before but was forgotten when the graph view
was refactored.
closesodoo/odoo#77330
X-original-commit: 624fd812c5d6b01c0cc11e8620dc703dc0370f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit replaces the control panel dropdowns with the new <Dropdown/> component, in order to get consistent through the new/legacy views (because the current Odoo version is in a state where some views uses the new infrastructure and some others are still not converted - see odoo/odoo#73311).
The diff seems massive, but it is mostly due to tests adaptations.
closesodoo/odoo#77001
X-original-commit: d679cd0d8ba9a2420e81a42a698763e9be2327e1
Related: odoo/enterprise#21077
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Consider the following scenario on a slow network in a graph view:
- add a filter (triggers a reload)
- toggle a measure (triggers another reload, before the first one
completes)
Before this commit, the new searchParams coming from the first
reload were lost, even though they were still displayed in the
search view.
This commit ensures that we keep the last searchParams when
reloading the graph view.
closesodoo/odoo#76918
X-original-commit: 1719de73099eca0b765237cb47caf44813157b94
Related: odoo/enterprise#21046
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit simplifies the props of the GraphView. We only keep
props that are necessary (e.g. for the dashboard view), and for the
others, we find the information in the arch. That way, there's only
one way to do, which is easier to understand.
We also remove the "display" and "title" props from pivot as they
weren't used.
X-original-commit: c26953ef15b0846282bbeccd7cf0de25e1a47392
Part-of: odoo/odoo#76918
Commit [1] fixed a bug in the legacy graph view and introduced a
test. This was done while we were re-writting the graph view in
owl. This commit adds the test added by [1] in the new graph test
suite.
[1] 11eb4542abclosesodoo/odoo#76778
X-original-commit: c5ac7fc541cbdb0a7fe7c9d01849bcc9a615a78c
Related: odoo/enterprise#20992
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Let's assume the following scenario in a graph view
- toggle a filter on a slow network s.t. it takes a while to load
- while it's loading, toggle a measure
Before this commit, the view was kind of locked after those two
steps, i.e. toggling measures or changing graph mode did not work
anymore (it could be unlocked by interacting again with the search
view though). The reason is that the new filter triggered a
re-rendering of the withSearch component (the parent of the graph
view), thus calling willUpdateProps on the graph view, which reloads
the data. Toggling a measure cancels the current load operation
(via keepLast), and the promise returned by willUpdateProps is thus
pending forever. From that point, only another re-rendering from the
parent (withSearch) could unlock the situation by cancelling the
previous rendering.
To solve this, we use the new Race primitive. It ensures that the
promise returned by load resolves as soon as the view is actually
reloaded (whether it came from the load itself, of by toggling a
measure).
This commit also refactors the pivot model to use the Race
primitive.
X-original-commit: ceebab7128cb9838024029aefe3910a18cf14e44
Part-of: odoo/odoo#76778
- PivotModel: methods are protected, not private
- PivotModel: rename meta into metaData (same as in GraphModel)
- GraphView: use the "useEffect" hook
- PivotView and GraphView typo: ArchParser is a class
X-original-commit: 71059a4887cf208552e4932ed2f3b6f53d75c369
Part-of: odoo/odoo#76576
When hovering header cells in the pivot view, the whole column is
highlighted. In comparison mode, a wrong column was highlighted
when hovering a measure.
X-original-commit: 751c2a78d375d67fc7e2cc20342d29188a3d11b5
Part-of: odoo/odoo#76576
Before this commit, it was possible to alter the table while it
was being reloaded (e.g. because a filter had just been applied,
or a measure had just been toggled). Those operations that altered
the table (e.g. sort rows, add groupby, expand group, close group)
typically cancelled the reload, which led to a situation where the
table was frozen, and only another reload from the search could
unfreeze it.
With this commit, we simply ignore all operations on the table
itself when it is being reloaded.
X-original-commit: dcdec74dca65e91998d90e3da0c14d8ee3df1567
Part-of: odoo/odoo#76576
Before this commit, if the user clicked on flip axis while the
data was being reloaded (e.g. just after applying a filter), the
reload was cancelled, and the axis wasn't flipped.
With this commit, we wait for the data to be loaded, and then
flip the axis.
X-original-commit: 5dc0631e339d04cc9f696490e73cf85d45b918fa
Part-of: odoo/odoo#76576
Let's assume the following scenario in a pivot view
- toggle a filter on a slow network s.t. it takes a while to load
- while it's loading, toggle a measure
Before this commit, the view was kind of locked after those two
steps, i.e. toggling measures, expanding groups, flipping axis did
not work anymore (it could be unlocked by interacting again with the
search view though). The reason is that the new filter triggered a
re-rendering of the withSearch component (the parent of the pivot
view), thus calling willUpdateProps on the pivot view, which reloads
the data. Toggling a measure cancels the current load operation
(via keepLast), and the promise returned by willUpdateProps is thus
pending forever. From that point, only another re-rendering from the
parent (withSearch) could unlock the situation by cancelling the
previous rendering.
X-original-commit: b9278e07b9ff01e608ccba6f4602eb9069213a46
Part-of: odoo/odoo#76576
Before this commit, if the user quickly clicked on several measures
(before the reload is over), only the last click was taken into
account. With this commit, all changes are aggregated such that we
only display the final result, with the desired measures.
X-original-commit: a4bae57e1f3b095a4e2d35b3da424c34df59b8dd
Part-of: odoo/odoo#76576
The View component supports banner_route, fetches the HTML and passes
on the prop "bannerHTML" to the concrete component class.
The feature has been a little forgotten in 0134495ba5.
This commit just revives it.
closesodoo/odoo#76370
X-original-commit: 99d1da58392a66dea1187ef4f00e41e924382d61
Related: odoo/enterprise#20779
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The view Component supports clicking on links `a`
that have a type="action"
The feature is a lighter version of execute-action, since it doesn't support
dynamic information from the model (e.g. basicModel)
X-original-commit: f695c61a7e9422cb2aa909d08d87ef74f42d3ed8
Part-of: odoo/odoo#76370
The search param "domains" of type Array was not satisfactory for
several reasons:
- useless for non reporting views
- too close from the search param "domain"
- a key "fieldName" was put on the value (resulting in a loss of
information in case of stringification)
We change it for a search param "comparison" of type null or Object.
closesodoo/odoo#76340
X-original-commit: 4f867099846c4214a74a7b0222ac0941537bbe29
Related: odoo/enterprise#20772
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We refactor the action service and allow the legacy and new views to share
a global state within a same action.
We introduce two new components View and WithSearch along with
the search infrastructure: ControlPanel, FilterMenu,...
Part-of: odoo/odoo#73311
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: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Before this commit, the result of the load_views was put in the cache, so a load_views could have been
triggered multiple times before the first of them returned
After this commit, the cahce works as expected and stores the whole Promise
We always delete from the cache Promises that are rejected (to let the user re-do it in the hope the situatuion has changed)
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
In this commit we have added new method name isHtmlEmpty in
kanban view. As we are convertting text field to html field,
we will need to check html field in if conditions.
As Html field will contain tags we cannot check it every time
perfectly. So, we need this method to make sure html field is
empty or not.
Task id: 2499504
X-original-commit: 2968dcea7fb58795eeb34949f4bbfc1029938cd1
Before this commit, the multi edition of a field using the daterange
widget wasn't really handled: only the field that was used for doing
the change (i.e. only the start or end date) was actually saved.
With this commit, the multi edit feature now supports the case where
editing a field actually triggers changes on other fields. All those
changes are displayed in the confirmation dialog.
Task 2555178
closesodoo/odoo#71545
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This is a forward-port of commit https://github.com/odoo/odoo/commit/970387f91fea0cb47404612f7d519ffba2c9ad3b
In editable list view, moving to next cell using TAB key crash when the
following field is becoming read-only (i.e non-focusable) and an onchange()
event is triggered.
Consider an editable tree view like this:
<form>
<field name="o2m" onchange="1">
<tree>
<field name="description"/>
<field name="date" attrs="{'readonly': [('description', '!=', False)]}"/>
<field name="type"/>
</tree>
</field>
</form>
1. Edit 'description'
2. Issue a TAB keypress before 'date' becomes read-only
It will crash while calling getSelectionRange() on an empty element.
opw-2523630
closesodoo/odoo#71163
X-original-commit: 2a880a8020b55b692505846e9626359fe019dbdb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbdb0
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.
task-2462676
closesodoo/odoo#71016
X-original-commit: 9d6ef842902e9e192924fa0caba99514e1543352
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
The PR https://github.com/odoo/odoo/pull/68799 tried to prevent the
form's edit button to bounce when quick editing.
The fix was wrong and some field continued to bounce the button.
This commit prevents the edit button to bounce when clicking on
any field by checking if we are quick editing.
closesodoo/odoo#69826
X-original-commit: 8393b3c51b38bd285acb91279cb08a28c241c9ca
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit we try to improve the way the events are displayed
to the user. Now, an event is displayed for each attendee of the event
that are selected in the filter. These events are displayed correctly
based on the status of the attendee in the event.
The colors displayed for the events now represent the attendees and not the
organizer.
If an attendee edit an event, it is edited for all others attendees.
Also, when an attendee that is not the organizer try to delete the event,
then the event is now declined in place of being deleted. If the organizer
delete the event, it is deleted for all attendees.
In case of an event where all attendees have declined it but the organizer,
the organizer see now a danger icon before the name of the event and it's
outlined and not filled with color, no matter of the actual status of the
organizer in the event.
task-2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
The calendar renderer used a template for events.
Now moved as a configurable template to ease futur calendar changes.
This commit adds also a custom event to the calendar renderer so that custom
implementations have a way to re-render the event items within the calendar
after making internal changes to the event records.
We introduce also a new option for a field "filter_field" which allows to specify
the field of the model in which we will save the status of a filter.
This is preliminary changes in order to make the calendar view able to modify
the attendance status of a meeting and refresh the events to visually display
if the user is attending or not.
Task ID 2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: jeh-odoo <jeh@odoo.com>
Since commit [1], a delay was added to "debounce" the quick edit to
check if the user did a click or a select.
Because of this delay, the edit button now bounces when clicking on
a field or label.
In this commit, we check if the user clicks on a "quick editable"
field or a label to prevent bouncing.
[1] https://github.com/odoo/odoo/commit/2939ea4dd4736e659cc3e4df2226a3b08ac8ec48closesodoo/odoo#68835
X-original-commit: 755a02135049f22e1e8db356169b5224f00c1f92
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit: all groupable fields were offered to selection when
a user would click on a suitable pivot header. While guaranteeing maximal
flexibility, this was easily overwhelming to any new commer.
After this commit: when at least one groupby is defined in the search
arch, the selection is done in the search arch groupbys (plus eventually
some custom groupbys) via a menu similar to the "Group By" menu in the
control panel. The advanced users have still access to more options in a
"Add custom group" menu again as in the control panel. When no groupby
is defined in the search arch, the selection is done among the groupable
fields as before.
This has led to a small modification of control_panel_model_extension.js:
it has become necessary to distinguish the groupBy filters coming from
the arch from those created by the user via the "Add custom group" menu.
Task ID: 2376505
closesodoo/odoo#61572
Related: odoo/enterprise#17341
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
A lot of tests in different QUnit modules need this delay to be
patched to 0. Some of them (e.g. the 'ActionManager > Misc' module)
didn't patch it correctly. It worked before because a patch was
done in a previous test, and wasn't unpatch. The previous commit
ensures the patch is removed, so now we have at least 2 tests of
the above mentionned module that fail. This commit ensures that
the delay is patched in every tests, and allows to specify a
custom delay if necessary.
For testing purpose, the multi-click timeout delay of the quick
edit is patched. However, in this specific test, it is patched
twice (once to set it to 0 in beforeEach, and once to set it to 50
in the test itself). A single call to unpatch removes the second
patch (50) but keeps the first one, for the remaining of the test
suite. This could lead to weird situations where the whole suite
passes, but a single test executed on its own fails.
Issue spotted in the assets revamp PR, as it alters the test order.
* sale_product_matrix
Before this commit, if we created a new row in an editable list view,
do not "touched" it and clicked out of the list then the record tried
to be saved and threw error notifications.
Now, that flow will discard the record to make it consistent with the
form view which discards the record when we leave the form.
task-2431691
closesodoo/odoo#68382
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Do not trigger quick edit when we are selection text with mouse:
- click and holding to select text
- multiple clicks selecting text
Since click on an editable field now change the edit mode, we could no
longer select the text.
With this change, quick edit is delayed by a given delay and if the edit
mode is not enabled if:
- there is a subsequent click within the delay
- there is a text selection when the click event is handled
closes#68023
X-original-commit: 2939ea4dd4736e659cc3e4df2226a3b08ac8ec48
With this commit we support adding FieldDependencies on custom widget, consider
FieldDependencies given on custom widget and add it to fieldInfo so that when
modal does calls to server to fetch data it consider those fields while reading
this will let us to design custom widget which may have some other fields in
dependency, say for example weekly recurrence widget which uses sun, mon etc.
fields, so with this we can fetch data of those dependent fields without adding
it to view.
task-2335399
closesodoo/odoo#60277
Related: odoo/upgrade#2021
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
add support of <widget> tag for owl, In order to prepare the future,
we want to convert everything in Owl, in future widgets generated by
<widget> tag will also be converted to owl.
with this commit we support widget to instantiate using ComponentWrapper.
task-2337692
Co-authored-by: Aaron Bohy <aab@odoo.com>
Philippe Wauthy