The old submenu "Add Custom Filter" of the menu "Filters" is now replaced
by a menu item "Advanced Search". Click on that item will open an
"Advanced Search" dialog in which the current search domain is displayed
in a domain selector. It is then possible to easily add/remove/edit some
parts of that domain before make a new search with the edited domain.
Task ID: 3269923
Part-of: odoo/odoo#118057
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Current behaviour:
If you export a view with a (some) filters and you set a custom
layout in the dashboard, you will get a traceback, preventing
you for accessing your newly exported dashboard.
Expected behaviour:
Should not crash when trying to view your exported view,
even with a custom domain.
Steps to reproduce:
- Install Dashboard, Sales
- Export from Sales > List View with a filter Creation Date before
XX:XX (date is irrelevant)
- Go to Dashboard > My Dashboard > Change Layout to something else
- Exit the page and retry to reopen it, a stacktrace is shown.
Reason for the problem:
When preprocessing the arch of the view in the dashboard, which is an
xml string, there is the domain included, which contains symbols that
are unparsable by `etree` unless escaped (like `<`).
Fix:
Escape the domain client side before being sent and saved in the database,
so when requesting it we don't have a parsing error. Then we unescape it when
the clients reads the domain from the server. The unescaping before
escaping is to avoid problem of double escaping when changing subsequently
the layout of the board view.
Affected versions:
- 16.0
- saas-16.1
- master
opw-3130117
closesodoo/odoo#112334
X-original-commit: bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the legacy implementation of the dashboard action, there was a
scss rule that set the height of the canvas of graph views inside
the dashboard to 300px. During the conversion to owl, this rule has
been lost. As a consequence, graphs in the dashboard look squashed.
This commit restores the scss rule to fix the issue.
Bug reported in the feedback pad after migrating odoo.com to 16.0.
closesodoo/odoo#110352
X-original-commit: 833f7394ecd88825990eb7d1b338e21bfbab55b5
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- add elements to dashboard
- enter dashboard and enable darkmode
Bug:
titles are unreadable because background is white
Fix:
remove CSS property
closesodoo/odoo#110201
X-original-commit: 5b56f1891d618008678d70ad125ad1393abe352b
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
auto_install is Falsy by default
author is Odoo SA by default
summary & description are empty strings by default
application is False by default
test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content.
closesodoo/odoo#106686
Related: odoo/enterprise#34462
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Go to Purchase -> Reporting -> Dashboard
- click on the "expand" arrows of the pivot view
- favorites - add to dashboard
Bug:
adding a view with no actionID causes the dashboard to crash on load
this [commit] prevents adding a view with no actionID
Fix:
added a default value of False to add_to_dashboard actionId
only display the option to add_to_dashboard for views that have actionId
opw-2965036
[commit]:https://github.com/odoo-dev/odoo/commit/7180d948f084d4f68d1660cb884c95aaf41288faclosesodoo/odoo#106093
X-original-commit: ff926a5b4390b38db339440c18dd2d5380df7d61
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Since cb5cca7, there are two "Dashboard" apps on the home screen.
The new one becomes the main Dashboard app.
The module `board` is not deprecated but it won't be advertised
as a full app anymore. It will continue to work on databases where it is
installed under a new menu item "My Dashboard" in the Dashboard app.
closesodoo/odoo#100260
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The cache key of _get_bindings was not super efficient.
The result of _get_bindings is cached,
but its performance was altered by the cache
key which requires to fetch the user groups for each call to
_get_bindings.
Besides, as there is a lot of possible group
combination, this resulted in a lot of possible cache keys,
and therefore a lot of cached values.
This revision aims to make _get_bindings more efficient
by:
- do not use the groups in the cache keys (less cached values)
- filter out actions not available to the user groups after
retrieving them from the cache
- use has_group to do the above, which is itself cached as well,
and therefore do not need to fetch the user groups
at each call to get_bindings.
In addition, move get_bindings from `get_view`
to `get_views`. If there was 3 views asked by `get_views`
(let's say kanban, list, form)
`get_bindings` was being called 3 times, through `get_view`
with each time the same arguments and therefore the same result :-).
Moving it to `get_views` allows to call it only once for all view types
requested, and for the web client it doesn't change much,
as it always request the toolbar/get_bindings through `get_views` only.
In addition, add the lang to the cache of _get_bindings.
it was actually a bug not to put it: if you had 2 users
with the same group set, using 2 different languages,
the user accessing first the get_bindings would cache
the action names within his language, and then the second
user would see the action name within the language of the first user
:-).
Before
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 790 ms, sys: 104 ms, total: 893 ms
Wall time: 1.7 s
```
After
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 23.5 ms, sys: 9.12 ms, total: 32.7 ms
Wall time: 36.9 ms
```
Part-of: odoo/odoo#99417
Before this commit, if a touchstart event is performed on a row in an
x2many, then a crash is displayed.
We also use this commit to rename the hasSelector props to allowSelector.
allowSelector is true if checkboxes can be present.
How to reproduce:
- go to a form view in mobile mode with an x2many field
- touch a row in the x2many (trigger an event touchstart)
Before this commit:
An error is displayed
After this commit:
Nothing happens.
closesodoo/odoo#98893
Related: odoo/enterprise#30773
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit rewrites the board action in owl. Legacy actions are
still supported inside this new board thanks to a compatibility
layer.
Part-of: odoo/odoo#92475
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>
Before, when we added view to the dashboard, context was saved too,
including allowed_company_ids. As a result when we checked the same view
from the dashboard, the displayed records corresponded to the active companies
during the time the view was saved and not the current ones - the companies
that are currently ticked from the multi-company widget.
After the fix, the displayed records in dashboard, correspond to the currently active companies.
task - 2809597
closesodoo/odoo#94105
X-original-commit: 9f854262a197782793d329487792a09a101a1a38
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the code of the `add_to_dashboard` method did not go
through the get_view override of the board model. Because of that, it
did not get the arch of the current board, which means that each
add_to_dashboard call was actually a complete reset: it was not possible
to add an action without removing the current board state.
For reference, this was caused recently by a change in commit b03c227e88.
The fix is basically a localized revert of that commit.
closesodoo/odoo#90830
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
It also adds `useService("rpc")` when component needs it.
closesodoo/odoo#85389
Related: odoo/enterprise#24745
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps :
Install Project and Dashboard.
Project > My task > Favorites (search zone) > Add to Dashboard.
Notice you can drag task between stages.
Issue :
Dashboard > Notice you cannot.
Cause :
m2m groupby normally (in kanban_renderer.js) does not allow drag.
project_kanban overrides its _setState() method to allow it for parsonnal
stages, because they "become m2o" with a user.
Yet, in the dashboard, we pass through the default method, because the
wrong view is created.
Fix :
Take into account the js_class in the arch to create the view.
opw-2752072
closesodoo/odoo#85033
X-original-commit: 4d864c05dfa8f9be25d41bbae318f75a61d0cde2
Signed-off-by: Géry Debongnie <ged@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
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 commit 3862d5aae1df72d3585f915e8a2a2626322e74ad has changed the class
set on the root node of the graph renderer but has not adapted a css rule
used in the board app to ensure that the graph views have the correct
height. We fix that situation.
closesodoo/odoo#80047
X-original-commit: b08bc57d5ba2e0da17a452189d584574fb2f9832
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Since 40f1ae87e1436192a70a8a7432eb72d379cfa6dc, a view added to the board application would not
have the correct domain:
- the action domain was not kept in the saved domain
- the saved domain was kept dynamic, leading to possible crashes
e.g. a condition like ("user_id", "=", uid) in the saved domain
would make crash the dashboard app.
We fix the problem and add a test.
X-original-commit: 7e77bb74bfa1bfef92c6d385dedc2d89e0040780
Part-of: odoo/odoo#80047
During the refactoring of the legacy control panel done in d679cd0d8ba9a2420e81a42a698763e9be2327e1,
the method "_addToBoard" was renamed as "addToBoard", but a call to _addToBoard
was left, breaking the keyboard navigation. We fix that situation.
X-original-commit: 6aa10e8c9118eba3c19563431c57912108fe12b9
Part-of: odoo/odoo#80047
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 handles the adaptation of any component using the search
model's 'action' and/or 'view' key, now replaced by the environment
keys 'actionContext' and 'viewContext'.
Affected modules are:
- base_import
- board
- crm
- google_spreadsheet
- project
X-original-commit: 40f1ae87e1436192a70a8a7432eb72d379cfa6dc
Part-of: odoo/odoo#77463
The pivot and graph views have been rewrote in owl in [1]. However,
the former implemention has been kept as it is still used in some
cases (e.g. board application, studio, PieChart widget), but they
are lazy loaded [2].
Before this commit, both the new and former implementations mostly
shared the same DOM (in particular, their root element had the
same classnames). It means that the scss rules of an implementation
might interfer with the other, and vice versa.
This commit adds the "legacy" keyword in the root classnames of
those views, and properly namespaces the scss rules of legacy views
to properly dissociate the style of new and legacy views.
For the pivot view, we re-used the same scss file, so in this
commit, we duplicate it (one for the new view, the other, lazy
loaded, for the legacy view).
[1] 0134495ba5
[2] bd3cf85c841168dfd87f7166b545dd00d9b38bf4
closesodoo/odoo#77323
X-original-commit: 3862d5aae1df72d3585f915e8a2a2626322e74ad
Related: odoo/enterprise#21223
Signed-off-by: Géry Debongnie (ged) <ged@openerp.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>
Since commit 0134495ba5 the reporting
views pivot, graph, cohort are written in full new framework.
Some applications still need the legacy ones, so this commit just implements
the lazy loading of those views.
In stock, report_stock_forecasted has been adapted in order to avoid having
a GraphView override: we now modify the canvas' height in pure JS.
*: board, stock
closesodoo/odoo#76931
Related: odoo/enterprise#21054
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
exportLocalState -> getLocalState
exportGlobalState -> getGlobalState
saveParams -> getContext
Moreover, the last one no longer returns an object with a "context"
key, but rather directly returns the context itself.
closesodoo/odoo#76576
X-original-commit: 12111f114c096c50adbb87cea9f1dd97dc16c47d
Related: odoo/enterprise#20894
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit will fix some display errors :
- The margin space between two btn-group on the control panel was too big;
- The "Group By" menu was lacking an option to add the "fa-caret-down" to looks like other
Dropdowns;
- The "Group By" menu on the graph view, when used as a subview, has been place in its own
btn-group to behave exactly as the "Measures" menu;
- The background of the headers on the pivot table wasn't always gray;
- Some borders of the pivot table were missing.
closesodoo/odoo#76529
X-original-commit: 0ffe18927c2f086529de168b5665766a1b9261f7
Related: odoo/enterprise#20872
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
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>
This commit moves the content of the static board files to a dedicated
`legacy` folder to mark the transition with the new Owl environment.
Part-of: odoo/odoo#73311
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
A number of functions from `web.test_utils` have been deprecated at
the module root and should be called through submodules.
Fix a bunch of remaining cases. Also add a few missing `await`s on
`triggerMouseEvent` calls. Don't bother rewriting the imports in
unpacking style as for most updating the imports is unnecessary. Do so
for `field_one2many_tests.js` where we have to rewrite the imports
anyway:
* recursively import controlPanel, createView, mock.patch and
mock.unpatch
* remove the aliasing of controlPanel to cpHelpers
Pierre Paridans