Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
*: account, base_import, board, website
This PR enhances the "cog menu" by fixing several UX flaws.
Notable improvements include:
- Reordering entries in a more logical manner, enhancing user intuitiveness.
- Assigning icons to common actions for quick comprehension.
- Grouping both print actions and module-specific actions for better organization.
Enterprise:
- https://github.com/odoo/enterprise/pull/41851
task-3337951
task-3355224 (milk post-merge fixes)
part of task-3326263
closesodoo/odoo#124413
X-original-commit: 596772885a87016d29f002cd4e41b5a973965e40
Related: odoo/enterprise#42212
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
Before this commit, on a dashboard having a multi-column layout, the
user couldn't see all those columns' actions when the layout fallback to
the "1 column" on a small screen.
This commit fixes it by, not only keeping the fallback to "1 column" to
optimize the screen's real-estate, but also properly bringing the hidden
columns' actions in the single column, so they become accessible by the
user.
Steps to reproduce:
- Create My dashboard on PC with two views set one next to the other
- Open My dashboard on mobile devices, and you see only the action
inside the column on the left and not the action inside the columns on
the right => bug
opw-3145706
closesodoo/odoo#124360
X-original-commit: fa1da53af1d327c4fafd944547dbf3c7312a93b4
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Steps to reproduce:
- Create My dashboard on PC with two views set one next to the other
- Open My dashboard on mobile devices, and you see the desktop view
=> bug
On small screens, we don't have enough available space on the screen to
allow other layout then "1".
opw-3145706
closesodoo/odoo#123561
X-original-commit: 9e1f79156e9440b953e9d476a608f9ce117c0d5b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, the svg icon of `board` had duplicate `viewBox`
that breaks the svg.
This commit fixes this issue.
task-3343278
Part of task-3326263
closesodoo/odoo#123067
X-original-commit: 48c8c6b32951e6393e41f2705dbdd9020dae971b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This reverts commit bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c.
Since that commit, the domain may be double-encoded in the database if
the user reorganizes the layout of his dashboard: once by the JavaScript
code, and once by the serialization of the innerHTML property.
However, there is no need to have it double-encoded, and some tools such
as the upgrade scripts will fail upgrading the domain.
With this commit, we are serializing the document to XML instead of HTML
and therefore the produced output is valid XML that will be correctly
interpreted by all the tools.
However, double-encoded domains might still be present in existing
databases, so we also need to take this into account when reading the
domain.
OPW-3130117
closesodoo/odoo#123045
X-original-commit: dd8f2640a281b86b73d3b296dd0a5aec7664eb4f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
There is no action that uses the search models/components available in
the legacy control panel. We remove those.
closesodoo/odoo#121433
Related: odoo/enterprise#41078
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit : The library underscore.js and
underscore.string.js were used in the ODOO solution.
After this commit : Every usages of a function from
underscore.js lib has been replaced with native javascript.
The goal is to remove all usages of underscore.js and to
not use anymore this library in ODOO.
---
TaskId : 3246238
closesodoo/odoo#120437
Signed-off-by: Géry Debongnie <ged@odoo.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
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
Louis Wicket (wil)