Add a maxLevels param like the jQuery.nestedSortable has. The goal of
this param is to set the maximum depth of nested items the list can
accept. If set to '0' the levels are unlimited, it's the default value.
task-3439226
Part-of: odoo/odoo#136375
*: board, website
This commit simplifies the UX of the 'Custom Group by' menu. Before this
commit, many clicks were needed to apply another filter, from an accordion
menu.
Now, a select element is used instead, allowing a better user experience, by
enabling such group by directly, when an option is selected.
Some tests have been adapted to the new selectors and behaviors, and the
applyGroup and toggleAddCustomGroup has been removed, since groups are applied
when selected, and the value can be modified directly with selectGroup.
task-3458519
closesodoo/odoo#132006
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
PURPOSE
Slightly modify various apps to improve the user experience. Changes include
notably labels and views fine tuning, roundings, and small css fixes.
SPECIFICATIONS
- Remove the decorator from the event list view as it's a bit confusing
- Ensure mailing KPIs are now shown with 2 decimal places
- Re-order the mailing stat buttons
- Improve the background / font colors of the cover block
- Improve the labels of:
- Title and confirm button of the /button and /link modals
- Confirm button when archiving a record
Task-3204554
closesodoo/odoo#128108
Related: odoo/enterprise#43937
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit brings a simple improvement.
There is no need to reposition an element while
you are scrolling inside of it.
closesodoo/odoo#137139
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The style was introduced with commit [1]
but then its only usage was removed in [2].
[1]: af89b46c5b
[2]: 59f4d112abf1eb175214614f9a84fc0c7a4af932
closesodoo/odoo#137309
X-original-commit: 22ccb0e795637864706a9933a23f605590a1f36e
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Purpose
=======
Always show the sum of a property column if its type is integer or float.
When we group records we don't show the sum, because it will require
to be able to aggregate properties (`properties.xxxxx:sum`) and the
technical cost is too big for the feature it gives.
Task-3468750
closesodoo/odoo#133700
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The goal of this commit is to fix two problems in the Many2one field:
1. At setup, the field is considered to be isFloating when its value is false.
2. When "xxx" is encoded and "Create xxx" is selected, the field is still
considered to be isFloating even the selection.
isFloating should only be true when the user is performing a search, when
they have made their choice isFloating should be set to false.
These problems should result in the external button not being displayed
in these two cases. Currently, the button is displayed correctly due to
a bug in owl. The bug in owl causes all Components that have executed
evaluateExpr with record.evalContext will be render each time record.update
is called. For example, for Many2oneField, it is the call to dynamic.context
in extractProps that will cause the rendering of the Component Field
containing Many2oneField. This will trigger a call to onWillUpdateProps
each time record.update is called, and will modify isFloating to make it correct.
In order to fix OWL without introducing any bugs, we're going to fix these problems.
How to reproduce after OWL is fixed:
====================================
Case 1:
------
- Go to a form view with an field "x" (with an onchange) and a many2one field
- Create a new record (the many2one field is empty)
- Edit field "x"
- The onChange returns a value for the many2one
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
Case 2:
------
- Go to a form view with a many2one field
- Insert "blabla" in the many2one
- Click on "Create blabla".
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
closesodoo/odoo#137212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The initial motivation of this commit was to ensure that the qunit
test suite doesn't stop when an error is thrown in a test, which
could happen if the error was thrown "sufficiently close to the
end of the test". Indeed, the "unhandledrejection" event being
async, it was sometimes triggered after the end of the test, when
the service registry was already reset, and the check of the
presence of the error service was wrong, so the error event wasn't
default prevented (e.g. await makeView(...) and the view crashes
at render time).
This led us to rework in more depth the way we deal with errors in
tests. Here are a few behaviors we want (probably not exhaustive):
- an error in a test must never end the suite (executed in py)
- an error in a test must always make the test fail, except if the
error is expected in the scenario, which one must be able to
state
- a test must always wait for potential unhandledrejection events
to be triggered before ending.
- ideally, we don't want to have to deal with unhandledrejection
in each test throwing an error (in order to prevent the suite to
stop)
To achieve this, we come with the following solution. We introduce
a new assertion method, "expectToThrow" which allows to state that
during the test, we expect errors to be thrown. It takes a list of
error messages that will be compared at the end of the test with
the errors that have been thrown during the test. If they differ,
a qunit failure is pushed and the test fails. If an error occurs
in a test and "expectToThrow" hasn't been called, qunit is directly
informed of the error and a failing assertion is done, make the
test fail as well.
If the error service isn't available in the test environment, we
apply the logic above when an "error" or and "unhandledrejection"
event is thrown. If the error service is available, we wrap the
default handler (typically the one that handles everything that
hasn't been handled by specific handlers, like tracebacks) and if
we get to it, we apply the logic above. This means that one must
call "expectToThrow" if
- the error service isn't deployed, or
- the thrown error is handled by the default handler, because
it is something like a traceback (errors like UserError,
ValidationError are graciously handled by the RPCErrorHandler)
and thus never reach the default handler.
In all cases, we prevent default the event such that the error
doesn't make the python test end.
Finally, to ensure that "undhandledrejection" events are handled
before the test ends, we wait, in the qunit lib, for a setTimeout
before ending the test, which ensures that all such events have
been dispatched.
closesodoo/odoo#137120
Related: odoo/enterprise#48211
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Issue:
If the user does not pass hide_label options then the tooltip appears twice.
Fix:
In this commit we have removed the null tooltip.
Example:
<field name="kanban_state" widget="state_selection" />
task-3475416
closesodoo/odoo#137281
X-original-commit: d39cfca349d5b623eb87f71f9996b3794de24378
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Prakash Prajapati (ppr) <ppr@odoo.com>
This commit introduces a new feature to the domain selector that allows
to toggle a new "include archived" option that alters the domain in a way
such that archived records are included or not. This domain part is naive
and may overlap with custom parts of the domain. The special domain part
which includes archived records (['&', <previous_domain>, '|', ('active'
, '=', True), ('active', '=', False)]) is invisible inside the domain
tree but remains visible in the domain code editor.
Also rename the "Match records with xxx of the following rules" statement
to "Match xxx of the following rules".
task-3482381
closesodoo/odoo#135861
Related: odoo/enterprise#47599
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
**Preliminary note**
The fix mentioned in this commit is already done
in another commit [1].
The below commit message stayed the same for history's sake.
**Before this commit**
A popover would close on outside mousedown event.
This is not sufficient enough, has for instance all the draggable stuff
makes use of the pointer events instead of the mouse events.
This lead to some unwanted behavior, i.e.:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover remain open and its position is not updated.
The dialog's dragging is fine.
**After this commit**
The popovers will close on pointerdown away events.
Now:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover is closed and the dragging still works as expected.
[1]: 76665eb400168a6fd6e2b5f5fe099c8c4e9c8a5e
closesodoo/odoo#137247
X-original-commit: c63dbc4ed0a04e34571c2929f43812873b62fd16
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
With this commit, instead of `Record.insert()` before setting
relation with records, we can immediately pass record data.
For example:
```js
message.author = { id: 3, type: "partner", name: "Admin" };
thread.messages.add({ id: 10, body: "some-text-content" })
```
This is supported on all relational fields that define a target
model.
To make this work while drastically avoiding cyclic dependencies
in code, whenever data have to be inserted in relation, they are
pre-inserted with essential data, and then they are fully inserted
after being registered in the relation.
closesodoo/odoo#136539
Related: odoo/enterprise#47854
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Modify the website's menu to include only two items: a link to a page
and a dropdown menu.
- Switch to mobile preview.
- Open the "Hamburger" menu.
- Click on the dropdown toggle.
- Bug: The dropdown menu is hidden and requires scrolling the navbar to
see it.
Since commit [1], dynamic positioning of dropdowns within a navbar has
been enabled (before that, Bootstrap disabled it) but this change
introduced this bug.
To fix this, we disable dynamic positioning of the dropdowns when they
are inside a "Hamburger" menu.
[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
opw-3493512
closesodoo/odoo#137165
X-original-commit: 55bc21c9503bf3b319d94e10d73bf672385b455c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This commit aims to reintroduce CSS variables to handle the different
states of our navbar entries.
Recently, the way we handle the navbar entries changed. Previously, we
used to set CSS variables in Community, which would allow us to control
the color of ours nav entries at every state.
On the Enteprise side, this would allow us to use the different colors we
use for these buttons and style them differently
This approach was also very helpful because we could override these CSS
variables once again to handle the colors of the Studio navbar elements.
Recently, the approach used to control these elements changed :
- On Community, we make use of CSS variables ;
- On Enterprise, we use the Bootstrap `btn-light` class.
Using `btn-light` was a very good approach to ensure that no issues would
appears on our buttons and also to reduce the amount of code needed, but
unfortunately, using `btn-light` directly affects Studio, causing contrast
issues. It was also a bit weird to have CSS variables + Bootstrap classes
being set at the same time.
To fix these issues, we reintroduce CSS variables in Enterprise and Studio,
to fully control the color of our elements and ensure everything is
readable. Most of these variables are defined in Community, inside the
`navbar.scss` file, and we simply override them in Enterprise and Studio.
task-3418936
part of task-3326263
closesodoo/odoo#137140
X-original-commit: af6d914c379953d2deec9833579399f126076194
Related: odoo/enterprise#48174
Signed-off-by: Stefano Rigano (sri) <sri@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
This commit introduces the publicComponentService, which makes it easy
to mount OWL components in the front end. All public components will share
the same env and therefore the same services.
To define an OWL Component in a public template, first create an owl component
and add it to the "public_components" registry in javascript, then use
<owl-component name="key"> in the template, where key is the key you used when
registering your component. If you want to pass props to your component, you can
give it a props attribute in the template, containing the props as JSON.
Example:
My Public Component:
```js
class MyPublicComponent extends Component {...}
registry.category("public_components").add("my_public_component", MyPublicComponent);
```
My Public Template:
```xml
<templates>
...
<owl-component
name="my_public_component"
props='{"title": "My First Public Component"}'/>
...
</templates>
```
Part-of: odoo/odoo#136159
Co-authored-by: Samuel Degueldre <sad@odoo.com>
This commit changes the default label of the graph view's axis to None
instead of undefined.
task-3519566
closesodoo/odoo#136822
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
This commit fixes a bug where popovers could stack up in kanban if one
kept opening them. By changing the event to close popovers from a
mousedown event to a pointerdown event, it is no longer stopped by the
draggable hook and executes correctly.
closesodoo/odoo#136890
X-original-commit: 76665eb400168a6fd6e2b5f5fe099c8c4e9c8a5e
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
When a user is editing an Autocomplete, we don't want to delete its value
if the props value changes.
For example:
- In a form view with a many2one field and another field with an onchange
- Edit the second field
- Insert a value in the many2one input
- The onchange of the first field returns a value for the many2one
Before this commit:
The value inserted in the many2one is lost. It is replaced by the
onchange value
After this commit:
The value inserted in the many2one is unchanged.
closesodoo/odoo#136654
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
when cropping a non-supported image in email marketing, it should trigger
a warning but instead throws a traceback error. This issue is due to
snippet.options.js being in legacy JavaScript, which doesn't include the
expected methods from the 'notification' service directly. Instead, it uses
methods from 'makeLegacyNotificationService' that lack the .add() method.
After this commit:
Added the add() methods in the 'makeLegacyNotificationService' which will
resolve the error.
task-3488181
closesodoo/odoo#136611
X-original-commit: 785e0d7ac12e51ce5db611e535f185a2345241ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Commits:
[IMP] devtools: add svg elements detection
[FIX] reactivity: do not notify for NOOPs on collections
[IMP] app: export apps set as static property
[IMP] runtime: do not check template equality outside dev mode
[FIX] runtime: properly support t-foreach on strings
More details: https://github.com/odoo/owl/releases/tag/v2.2.6closesodoo/odoo#136591
X-original-commit: c92f9f8a7de6e10354ec0feea64bfc045a0edafb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: analytic, base_automation, loyalty, mass_mailing, project, web, web_editor, website
This commit adds many new documentation of options and their usage for
fields. This makes them more usable and customizable in Studio, and adds
documentation for developers to know the type of expected option.
Some options that might lead to issues or that are too technical have
been removed, as they are not relevant and not required in most use cases.
task-3469741
closesodoo/odoo#134858
Related: odoo/enterprise#47148
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit removes the files ajax.js and rpc.js then adapts all the
places where their exports were used. For most of the changes, it's a
replace of `this._rpc({...})` by a new `useService("rpc|orm")` like
pattern in the widgets.
closesodoo/odoo#136271
Task: 3439226
Related: odoo/enterprise#47775
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduce:
1. Open "Sales" app.
2. Open the fist step about company data
3. Hit "Save"
4. The step should have been marked as complete
onboarding: Since the relational model refactoring,
saving a record that is not changed will not result in
calling the onRecordSaved callback, while saved will be `true`
in `saveButtonClicked`.
web: Be more explicit about this fact in the onRecordSaved doc.
Task-3516270
closesodoo/odoo#136143
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit simplifies the implementation of ReferenceField and makes
it fully reactive.
Currently, the ReferenceField is not automatically rendered when the
relation is updated from the component. The problem does not currently
occur because when a field is updated, a delete is performed on the
invalidField Set, which causes all the Fields to be rendered. This
behaviour is a bug in owl. Performing a delete on a Set that does not
delete any values should not trigger reactivity. When this is fixed, some
tests will no longer pass.
closesodoo/odoo#136433
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
steps to produce:
- when measure field value set null if value is zero.
- try to open cohort/graph view measure.
- trackback occurs 'value.toFixed is not a function'.
Fix:
This commit, fixes the trackback when the measure value is null or undefined.
It occurs when the measure field value is null in a particular condition.
closesodoo/odoo#135207
Task: 3502869
Related: odoo/enterprise#47572
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit ensures that changes in translated fields on a freshly
duplicated record will apply to all translation even when the user
language is not en_US.
Steps to reproduce:
-go to accounting -> configuration -> taxes in other language than en_US
-open any record in form view
-duplicate the record
-change the name of the record and save
-ensure that the name is the same in all languages
task-3339736
closesodoo/odoo#134481
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Report footer is sometimes misplaced in settings preview.
We change the css to always stick to the bottom of the preview,
no matter the content height.
Task-3145445
closesodoo/odoo#136534
X-original-commit: 9be75bb17063c6b0207aa82144e9f44b6e49dc45
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Report body size was too narrow to render bootstrap .col as column,
the media query consider the report as a mobile view.
We unlock this limitation to let customer add column in the footer.
Task-3145445
X-original-commit: 3631e51e224e843cf6b6cd1da82592be4cb9397f
Part-of: odoo/odoo#136534
Prior to this commit, there was a spacing issue in large screens (eg. 4K
screen), the form view wasn't large enough and this created a big gap
between the form view and the chatter.
This commit adapts the form view to large screens.
task-3453381
Part of task-3326263
closesodoo/odoo#136454
X-original-commit: 1a995cad898283f6909506ba43d1692381b3d6ef
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When the onchange triggered by an x2m fails on the parent record,
we want to reuse a valid value (the one before the onchange).
How to reproduce:
- Go to a form view with an x2m (onchange=true) that contains at least one record
- Edit the record in the x2m
- onchange on parent record fails
Before this commit:
The value is unchanged.
After this commit:
The value of the edited field is replaced by its old value.
closesodoo/odoo#136450
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes a loophole in the evalContext used in form,
list and kanban views to evaluate python expressions (modifiers,
domains and contexts). Before this commit, the evalContext was a
mix of different things:
- keys of the current context (which also contained keys from the
user context);
- a key for each field in the view (allowing to use field values);
- a "parent" key in the case of x2many records (allowing to go up
to the parent record values).
- "active_id", "active_ids", "active_model", "current_company_id".
All those keys were mixed in the evalContext, and they could
obviously conflict (e.g. if there was in the context a key which
was also the name of a field).
Even though the evalContext didn't contain an explicit "context"
key, expressions like `context.get("x")` worked. This was because
the python evaluator automatically adds the whole evalContext as
value for the "context" key if this one doesn't exist. This allowed
people to also access field values with `context.get("fieldName")`
and thus bypassing the view validation, which ensures that
everything used in those expressions is either a py builtin
supported by pyjs, a field name which is in the view or some other
whitelisted keys ("uid", "allowed_company_ids"...). Fun fact:
people did it, in a form view that is used on two different models
(product.product and product.template).
With this commit, the context (and user context) keys are no longer
spread into the evalContext. Instead, a "context" key is added.
Two special user context keys can still be accessed directly though,
without doing `context.get("...")`: "uid" and "allowed_company_ids".
The reason why we keep them is simple: those were the two only keys
that could be used directly as they were whitelisted by the view
validation. The client also evaluates domains and contexts coming
from actions and from search view filters. In those cases, the
evalContext is simply the context, and those two keys are widely
used. So it's easier if we know that, e.g. "uid" can be always
directly accessed, whether we're in an action domain, in a search
view or in a form/list/kanban view.
To summarize, accessing a context key must always be done through
`context.get("...")` except for "uid" and "allowed_company_ids",
which can still be accessed directly. This doesn't change from
before. What changes is that a record field can no longer be
accessed with `context.get("...")` (which kind of allowed to bypass
the view validation).
closesodoo/odoo#135782
Related: odoo/enterprise#47522
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This commit changes the canOpen prop of the many2oneAvatar field to be
set to true only when in form view. The field will therefore stop being
a link in readonly when outside of form view.
closesodoo/odoo#136118
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The safeConvert function in the useDateTimePicker hook will call parseDate with
an undefined format when no format option was provided to the hook. Before this
commit, since the options object passed to parseDate still contained the format
property, the undefined format will also be passed on to the parseDateTime
function. This is problematic, because now the parser will use the default
datetime format, and it will fail because of the absence of a time value in the
input string.
For some input formats, parseDateTime will still yield the correct result using
one of its backup parsing methods. However, a wrong result will be returned for
date formats containing some textual parts (for example MMM/dd/yyyy).
Making sure no undefined format values are passed on in the parseDate function
resolves the problem.
opw-3478797
closesodoo/odoo#136221
X-original-commit: b04482ed87db05b3fc2523a08ce7ca5818af578b
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
The async methods of field service were not declared in its key async.
This would allow destroyed components to process the results of those
methods (despite an initial call to useService). We fix that.
closesodoo/odoo#135950
X-original-commit: 7955def19c7d4a8c49be472413423bbf3beec2e5
Signed-off-by: Géry Debongnie <ged@odoo.com>
* = bus, calendar, im_livechat, hr, project_todo, sms, snailmail,
test_mail, web, website_livechat
The current implementation often led to tests relying on DOM structure
to properly target the correct element with the text.
It is now easier to simply check if a parent contains some text.
closesodoo/odoo#136295
Related: odoo/enterprise#47770
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If a list view row switches to more than one line (e.g. because of some
field which overflows), the record selection checkbox need to respect
the same alignment as other 'blocky' widget like statuses, priorities,
etc. and be middle-aligned.
Task-3515864
closesodoo/odoo#136222
X-original-commit: 77252ff7201625f25667f64f07cee627d3c47b99
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Commit [1] changed the separator of cids in the url to make it
better looking, by using a character that doesn't need to be
encoded (namely, "-" instead of ","). However, by doing so, urls
still using the former separator couldn't be correctly parsed
anymore. This commit adds a small backward compatibility layer,
s.t. links in emails for instance keep working as before.
[1] abae4d4a5cclosesodoo/odoo#136247
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Include the 'duplicate' action in the action menu in list view. The copy_batch
method will call the copy method with a loop to keep any existing override.
closesodoo/odoo#133977
Task-id: 3456679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Up until this commit, which view was displayed by default on mobile was
somewhat of a lottery.
Initially, only kanban views were considered as 'more adapted to mobile
devices' and used as a main fallback to display records who had a kanban
view in the window action definition.
The the concept of 'mobile-friendly view' was extended to map and grid
so that these views could take precedence over the kanban view in
specific circumstances (indsutry_fsm and timesheet_grid, both of which
are enterprise edition apps) - basically they were marked as
mobile-friendly not because they *are*, but because it was the only way
to override the kanban override.
But this comes with its lot of problems and limitations, namely that the
mobile friendly view will be found based on the order of view modes for
a window action, so if you have a window action with the view modes
`kanban,map,tree,form`, you will never be able to have e.g. the kanban
view shown on desktop by default and the map view on mobile.
This commit introduces the notion of a 'default mobile view' on window
actions so that one may decide on an *arbitrary* view mode to use on
mobile for an action - without impacting the ordering of views on other
models, etc.
Task-3460374
closesodoo/odoo#133608
Related: odoo/enterprise#46562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, cids in the url (in the hash part) were
separated by a comma, which was encoded by encodeURIComponent as
it is not considered as a safe character, resulting into "%2C"
appearing in the url in between company ids. This was kind of ugly
and made the url a bit hard to read.
This commit uses "-" as separator for cids, which is a safe
characters [1] to use in the url and which is thus left untouched by
encodeURIComponent.
AL request.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#descriptionclosesodoo/odoo#136104
Related: odoo/enterprise#47723
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Romain Estievenart