Before this revision,
it wasn't possible, in the form header,
to organize buttons in nodes.
If you attempted to do so, the buttons were not appearing.
e.g. for the below form
```xml
<form>
<header>
<button name="0"/>
<button name="1"/>
<div id="special_buttons">
<button name="2"/>
<button name="3"/>
</div>
</header>
</form>
```
Before this revision, the buttons 2 and 3 were not appearing.
Adding this possibility can allow simpler inheritage,
for instance by organizing buttons in sections and then
the inherited view can add buttons directly within the right section,
using a selector targetting the section.
It also allows to restrict a button to users having 2 groups.
e.g.
```xml
<button name="action_draft" position="after">
<div groups="sale.group_auto_done_setting">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</div>
</button>
```
If you want to restrict the button `action_done` to users
having both `sale.group_auto_done_setting` and `sales_team.group_sale_manager`,
you cannot put both groups on the same node,
because otherwise it's an OR connection, not an AND.
`groups="sale.group_auto_done_setting,sales_team.group_sale_manager"`
means
"users has `sale.group_auto_done_setting` or `sales_team.group_sale_manager`",
not AND.
So, the only possibility to restrict a button to two groups with an AND
connection is to restrict the button to a group and nest the button
inside a block restricted to the second group.
The above example is an actual example/need from the existing code.
But, as this possibility wasn't there before this revision,
they achieved the goal by using the `groups_id` feature:
```xml
<record id="view_sales_order_auto_done_setting" model="ir.ui.view">
<field name="name">sale.order.form</field>
<field name="model">sale.order</field>
<field name="inherit_id" ref="sale.view_order_form"/>
<field name="groups_id" eval="[(4, ref('sale.group_auto_done_setting'))]"/>
<field name="arch" type="xml">
<button name="action_draft" position="after">
<button name="action_done" type="object" string="Lock"
states="sale"
help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver." groups="sales_team.group_sale_manager"/>
<button name="action_unlock" type="object" string="Unlock"
states="done"
groups="sales_team.group_sale_manager"/>
</button>
</field>
</record>
```
So they had to use an inerited view for that purpose only to restrict
the button to two groups. It's a work-around.
It is much simpler to allow to have nested buttons in the header of the
form.
closesodoo/odoo#98551
Related: odoo/enterprise#30643
Related: odoo/upgrade#3812
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Introduce a new Dynamic Placeholder Generator
in mass mailing and SMS creation.
Using a specific character (#) in subject or via the PowerBox in body
we open a field selector popup, which can be use to select
the wanted field and enter a default value. on validation, the dynamic
placeholder will be inserted in the corresponding input/editable.
task-2154624
closesodoo/odoo#71878
Related: odoo/enterprise#30333
Related: odoo/upgrade#3766
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose:
Improve performance/reduce server load for the status bar widget when
the underlying field is a m2o.
Before this commit:
The status bar widget does two calls:
- a search_read request to retrieve ids and folds
- a name_get to retrieve names
With this commit:
The name_get can be avoided to save a call by fetching display_name in
the search_read.
This commit removes the name_get call to retrieve the name directly
from search_read.
task-2919535
closesodoo/odoo#98164
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In legacy, when you have a label with a string attribute that is empty,
that label is rendered as empty. In the new form view, when the string
attribute was empty we would fall back to the default label for that
field, which is incorrect.
This commit fixes that by not rendering labels that have an empty string
at all.
closesodoo/odoo#98237
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
*: mail, web.
The pyEnv used during tests is based on the mock server to provide
server like api. This issue is that when creating multiple environments
during tests, a new mock server is created each time. This is not realistic
since in a real world scenario, multiple tabs would share a single server.
In order to make pyEnv work with multiple tabs tests (e.g. multiple env tests),
let's create a single mock server shared between js environment during a test.
task-2053917
Part-of: odoo/odoo#97975
The "name" attributes set on the filter nodes in a search arch are now
kept in the search items created from them. This will allow an easier
manipulation of search items (e.g. toggle a filter with a given name).
closesodoo/odoo#97913
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps to reproduce:
- Switch language to french
- Refresh the page
- Create a new payment
- Select a partner
- Enter an amount of 100000,00
- Save the record
-> The following field is incorrect: amount
Cause of the issue:
Since https://github.com/odoo/odoo/pull/97425 ,
`parseMonetary` wrongly assumed that a currency was always passed in
the parameters
opw-2937403
closesodoo/odoo#97861
X-original-commit: 9d518f847d2204fc5159a92bc4e4de655acf88fa
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce:
- Switch odoo language to french
- Create a client bill for Azure Interior of $1 000 000
- Confirm it
- Go to the accounting dashboard
- On the bank, click on reconcile
- Select Azure interior
- Click on the correct bill
- Switch to Manual operations
-> $1 000 000 is not a correct monetary field
Cause of the issue:
Recently in https://github.com/odoo/odoo/pull/94126 , `formatMonetary`
switched from joining the currency and symbol from ` ` to a non
breaking space, NBSP.
To parse monetary values, the behavior was to split around NBSP to
get the symbol on one side and the value on the other which is then
passed to `parseFloat`.
For the following examples, NBSP is replaced with an underscore.
So `$_1000` becomes `$, 1000`
But some languages such as french uses the same char as thousands
separator.
In that case, `$_1_000` becomes `$, 1, 000` and then the parse fails.
opw-2937403
closesodoo/odoo#97513
X-original-commit: 9d36722797669498dfd1ad4659e5f29347ba30f3
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
- Purpose
Improve the UX of the "column creation" mechanism in the kanban view
so that users better understand what it is they are creating.
- Specifications
In the kanban creation mechanism, use the name of field on the model
(e.g. when grouped by stage_id in project.tasks kanban, "Add a Column"
would become "Add a Stage" because the stage_id field's name is "Stage").
task-2755570
closesodoo/odoo#95550
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Commit b743fda doesn't seem to work properly.
Steps to reproduce:
- Open a spreadsheet A in one tab
- Open a spreadsheet B in another tab
=> the master tab should poll both spreadsheet channels but it
does not.
The condition here sheems wrong
https://github.com/odoo/odoo/blob/bf2ce0aa0c7d45c90d7ff104d5af5f99b29d59ae/addons/bus/static/src/js/crosstab_bus.js#L299
`peerChannelsBefore` is not really "before the channel was added".
It's "before outdated channels are cleared".
It already contains the new channel added to local storage by the slave tab!
Hence it wrongly returns `false` which means the poll request is not
restarted.
Additional fix required since e2aeb5f
-------------------------------------
Commit e2aeb5f broke a little more the feature.
It is assumed the ids in `channels` are matching the ids in `lastPresenceByTab`
(previously named `peers`). It was no longer true since `lastPresenceByTab`
is now managed by multi_tab service (with it's own id).
With those non-matching ids, channels from other tabs were always considered
outdated and therefore cleaned up.
Small comment on the change in the mock server
----------------------------------------------
Cross tab bus tests were not working properly.
The error message string "XmlHttpRequestError abort" was stringified
(stringifying a string), leading to "\"XmlHttpRequestError abort\"". Since the
implementation depends on the exact error message, tests didn't propely
reflect reality.
This is technically not needed anymore since bus tests are no longer using
the legacy mock server but it can't hurt to fix it. (the new mock server
doesn't have this issue)
closesodoo/odoo#97036
X-original-commit: f25f36a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Goaman <nby@odoo.com>
Co-authored-by: tsm-odoo <tsm@odoo.com>
This commit simplifies the component SCSS improving bootstrap
integration and allowing components other than 'SearchPanel' to use the
same tree-view design.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2795166
closesodoo/odoo#87687
Related: odoo/enterprise#25781
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The mock server's mockReadGroup function would not properly compute the
value, range and domain of the returned groups for date/datetime fields.
The value should be expressed in the local timezone,
and the range/domain shoulb be expressed in UTC timezone.
Consider the following:
- a record with a datetime field of value "2016-12-14 12:34:56" (expressed in UTC)
- a user with an UTC+2 timezone offset
- a read_group with groupby "['datetime:hour']"
The corresponding group would have had the following metadata:
- value: `"12:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 11:00:00"], ["datetime", "<", "2022-12-14 12:00:00"]]`
- range: `{ from: "2022-12-14 11:00:00", to: "2022-12-14 12:00:00" }`
It now has the following valid metadata:
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 12:00:00"], ["datetime", "<", "2022-12-14 13:00:00"]]`
- range: `{ from: "2022-12-14 12:00:00", to: "2022-12-14 13:00:00" }`
closesodoo/odoo#96946
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fields with widget `radio` and `boolean` can't be edited
Steps to reproduce:
1. Install Discuss
2. Connect as demo and go to your preferences (top right)
3. You can't edit your notification type
Solution:
Use widgetOptions' mode along with hasReadonlyModifier to disable the
fields
Problem:
This PR https://github.com/odoo/odoo/pull/88223 modified the value of
hasReadonlyModifier which is used to disable radio and boolean fields
opw-2898464
closesodoo/odoo#97106
X-original-commit: 6befccd7c8ac22fe4da2a741efeecde2d036a7b9
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce:
- install approvals
- in the approvals app go to filters>add custome filter> approval type
Issue:
- traceback
Cause:
- When no other module is installed, there is nothing to display under
the approval type filter. Even if the field is not required,
the javascript try to access the first element of the selection array
to auto-fill the menu.
Solution:
Add a check, if empty and not required, do not display it and leave the
field empty
opw-2895516
closesodoo/odoo#96617
X-original-commit: 7fdbb1783ec65919a709e5fcac111994d0eb3cd5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Co-authored-by: nle-odoo <nle@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
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: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
In BS5 there is a check to avoid having multiple handler for one
element and we can't add two components' instance on an element.
So, before disposing a tooltip we check if there is an instance of a
tooltip and we avoid instantiation of tooltip if not already done.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.collapse.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.carousel.
> Bootstrap doesn't allow more than one instance per element.
> Bound instance: bs.tooltip.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
* data('bs.popover') is not a jQuery data anymore
-> fetch data from the instance instead.
* use the new class name 'popover-arrow' instead of 'arrow'
* website_forum: offset is not a number anymore
-> Convert to string instead.
* BS5 event listener: 'focus' -> 'focusin'
* use `mouseover` event to show and `mouseout` to hide.
* disable at some point the animation to avoid remaining listener
in the DOM.
Ref:
https://getbootstrap.com/docs/5.1/migration/#popovers
Task ID: 2766483
Part-of: odoo/odoo#95450
Interrestingly enough, those missing ending square bracketsdoesn't have
consequences on the way the browser interprets these attribute
selectors... Anyway, for consistency sake, let's close them properly.
closesodoo/odoo#95070
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
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: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
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>
When creating a custom datetime field (with date option type) with Studio and
that you edit the field manually then validates with the ENTER keyboard, the
date is changed (one day is removed - mm/dd-1/yy).
Since [1].
Step to reproduce the issue:
1. Put yourself in Europe timezone (e.g. BE)
2. Add a datetime field via studio (e.g. on the product form)
3. Put a date widget (no datetime)
4. Enter a date manually mm/dd/yy
5. Hit ENTER without clicking outside the box
You will see that the final date will be mm/dd-1/yy.
Solution: The path applied when clicking outside the box and cliking ENTER is
not the same. In the ENTER path, we check if the type of the field is a
`datetime`, if so, we remove the offset TZ to match 00:00:00 instead of
02:00:00 (if you were in GMT+2 zone). The issue is that we do this offset
if the customm field (via Studio) is a `datetime`. This check is incorrect: we
can have a `datetime` field but a date widget, in that case, if we are not on
GMT time we offset by some hours and we end up the day before (as we offset by
2 hours starting from midnight which results in 22PM the day before and when
rendered as a simple date we "loose" one day).
[1]: https://github.com/odoo/odoo/commit/08a423577f732b65ad5035e8f4662386a8631c5f
opw-2830843
closesodoo/odoo#93293
X-original-commit: 37a58832bc966f28fb2c1d627dfe28cef4fb5de7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Step to reproduce:
- Open 'Sales'
- Open a SO
- Click on the product link in the OrderLine tree
Current Behaviour:
- Breadcrumbs are cleared
Since https://github.com/odoo/odoo/commit/cefd6ade293e6cfa8ec405f55c6d4d7194f36e7e the onClick is only triggered in form view
Behaviour after PR:
- Breadcrumbs are not cleared
Link are now trigger via another click action '_onLinkClick' and quickEdit does not trigger on URL click
Test provided by Anh Thao (pta)
opw-2748041
closesodoo/odoo#85203
X-original-commit: 8ba45fde9f248e5a2b76ff3e934d9784d5d57ff0
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In some cases, we want to use the regular FieldMonetary widget (performing the amount rounding correctly) but without displaying the currency symbol since the currency code is displayed elsewhere.
This is needed because some currencies are using the same currency symbol like USD / MXN.
Task: 2555114
Part-of: odoo/odoo#91448
In order to make the process of signing faster, automatic mode should be the
default one. This commit implements this behavior and adds tests for it.
task-2862209
Part-of: odoo/odoo#92340
Since 43474916 and ff37a2fe, the function `name_get` now returns an
empty string for missing records. This change was not reflected in
mockServer.
This commit also copies the tests of `name_get` on the legacy mockServer
to the "new" one. They were missing.
closesodoo/odoo#92473
X-original-commit: 638fab65cdf7a615138dee1395f54224b3ea1e77
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
It is very common when using kanban view to need a way to declare what
action is executed when clicking on a record. The default action
(switching to form view) is sometimes not what we would like. For
example, clicking on a project kanban record should open the
corresponding tasks, instead of the project form view.
Until this commit, it was not possible to do this simply for a whole
kanban record, however it was possible to add a button with a name and
type attribute to specify the resulting action. This commit introduces
the same idea, but on the complete kanban record, instead of just a sub
element.
To specify the action that should be executed when clicking on a record,
one can now use the 2 attributes 'action' and 'type' (which corresponds
to the 'name' and 'type' attribute for the kanban record. 'name' was
also considered, but it was too weird). For example:
<kanban default_order="name" action="action_brand_model" type="object">
...
</kanban>
Part-of: odoo/odoo#92071
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing assertion
(specifically in the list view column sizing tests).
As the difference is *really* small, introducing a margin of error (i.e.
<= 1px) looks reasonnable ; as implemented in this commit.
closesodoo/odoo#92203
Forward-port-of: odoo/odoo#92066
X-original-commit: 5f0353814fc314b75a34a38e700bd7f0797dd18d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
It is now possible to get access to the action context keys when the
search filters are evaluated. This means that a search arch filter like
<filter name="my_filter" domain="[('my_field', '=', context.get("my_value))]"/>
can be safely evaluated if "my_value" is in the action context (or in
the user context or is builtin as before).
closesodoo/odoo#91959
Signed-off-by: Géry Debongnie <ged@odoo.com>
The boolean_toggle should only be disabled when there is a readonly
modifier, not when the view is in readonly mode.
Cause of the issue
The input was disabled but the `_onClick` was registered on the
widget root node.
Solution
- Listen for clicks on the input element
- Override the render method to set the disabled prop according to the
readonly modifier.
opw-2739468
closesodoo/odoo#91601
X-original-commit: 29a2402153dc95414dad8c833487e7dd18c8a222
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Instead of having 4 buttons to select a view in calendar, we start using a
dropdown button with the framework data-hotkey approach.
task-2704432
closesodoo/odoo#81705
Related: odoo/enterprise#23131
Signed-off-by: Arnaud Joset <arj@odoo.com>
As result of [1], control panel's search menu-items were highlighted
correctly on ':hover', but not using a keyboard.
This commit assigns the default <Dropdown> 'focus' class on both
circumstances.
[1] https://github.com/odoo/odoo/pull/87448
task#2852217
closesodoo/odoo#91206
Related: odoo/enterprise#27355
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit:
- If the color attribute is set on a field on which the user might
not have access to the model / record, a traceback is returned. However,
in the case of a M2O, the name_get would be returned, so its is
a pity that the color raise an access error.
After this commit:
- A search_read is made instead of a read, which returns nothing if
the user does not have access to the model / record and does not raise
a traceback.
closesodoo/odoo#91147
X-original-commit: 3e8744418d629a62e9eacd16dfa4721921e02453
Related: odoo/enterprise#27318
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds some commands that can be used in the html editor.
Editor Commands
---------------
Some new editor commands have been added:
- */article:*
This command is available on every html field using the Odoo Editor.
This command allows to add a direct link to the selected knowledge article.
- */file:*
This command is only available in the Knowledge App.
This command allows to add a file (or an image) download button inside the
body. The user can choose a file to add from its own file directory or an
existing attachment already present in the database.
- */template:*
This command is only available in the Knowledge App.
This command allows the user to create a block where them can write and lay out
content destined to be reused by the readers of the article. The lasts will be
able to copy and paste it to send it as message or use it as a description on
other records.
No /command can be added inside a template.
Technical notes:
/file and /template commands can be activated in other modules by adding
knowledge_commands = True on the html field in the view where they should
be activated.
Task-2674460
Part-of: odoo/odoo#82315
Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Fabio Barbero <faba@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Aurelien Warnong <awa@odoo.com>
Currently, when we go to the planning > config > resource
(editable list view without any record) and create a ersaource
the color picker widget is resized vertically instead of horizontally.
In this commit we have fixed the issue, when there is no record in
the planning_resources list view, the color_picker widget gets 72px width by
default, so we have added a condition that if there is a color_picker widget
in a field, we will calculate the width based on the total fields in the view.
task-2720976
X-original-commit: d047080c18ea4c9314df5f2aefdfb6b7deeef45a
Part-of: odoo/odoo#90897
The recordId parameter was not necessary in the _updateComodelRelationalFields method
of the legacy mock_server
closesodoo/odoo#90497
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
An open dropdown stays opened if any other element stop a click event
closesodoo/odoo#90363
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when spawning a LegacyWidget with the standaloneAdapter,
the legacyWidget couldn't re-trigger an OdooEvent (trigger_up) in the DOM
forbidding any attempts to, for instance, execute an action button (a stat button in form view)
After this commit, not only standaloneAdapter takes an optional owl ref to trigger onto
(defaults to document.body), but the last resort legacy_provider handles execute-action
DOM event.
closesodoo/odoo#90172
X-original-commit: 616d0761a8e15dfe49db9bacdfa6f7df75587dff
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
Denis Ledoux