Previously, when evaluating a button's context from its attributes, we
would evaluate it with the record's data as context, this resulted in
x2many fields being evaluated as a datapoint (in particular, as a
StaticList). When we then went to call doAction with that context, the
action service tries to serialize that context with JSON.stringify,
which crashes as the StaticList contains circular references. This is a
mistake, as contexts and domain that are to be evaluated from a
string/attribute should be evaluated using the record's evalContext, not
its data. This commit fixes that.
closesodoo/odoo#98469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the conversion of the kanban view, it was no longer possible to
validate the quick-creation of a column using enter while within the
quick-create input, this is because the hotkey service ignores hotkeys
being pressed while within an editable element by default except for the
escape key.
This commit fixes that by configuring the enter hotkey that
is registered to bypass the editable protection, and also restricts this
hotkey to only be active while focused inside the input.
closesodoo/odoo#98535
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Previously, when registering a hotkey without an area then a hotkey with
area, there would be a crash, as that latest hotkey is the candidate
winner, and we then check that there is no other matching hotkey with an
area that's more specific. In doing this, we assume all other candidates
have an area and call it as a function, but since some hotkey
registrations don't have one, we get a crash.
This commit fixes that by filtering the candidates to only those which
have an area before trying to narrow down to the most specific one.
Part-of: odoo/odoo#98535
Before this commit, when creating a record containing an invisible
x2many, the fields related to this x2many were not asked during the
creation onchange.
Problem:
Some required values were missing when igniting a new record.
Cause:
The arch related to an invisible x2many was ignored.
closesodoo/odoo#98086
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
# Issue
A Dropdown is not closed when a child ViewButton is clicked.
# Solution
Make the ViewButton close the Dropdown.
# Note
Usually, a dropdown is closed by a DropdownItem component.
This is not the case here, because the clicks on view buttons are stopped
(see the view button template). Letting them bubble would close their
eventual parent dropdown, but it brings other issues (e.g. for a view button
in a list renderer's group row, or view buttons that could get interpreted
as action links under some conditions <a type="action" .../>).
Instead of looking in the env to close the parent dropdown if any,
an alternative solution would be to extend the ViewButton component,
wrap it in a DropdownItem component, and reroute its `onClick` handler
to the DropdownItem's `onSelected` prop.
But this requires some preparation at the form compiler level
(when compiling the status bar buttons), which we thought was overengineering
at the time of writing.
closesodoo/odoo#98399
Signed-off-by: Samuel Degueldre <sad@odoo.com>
*: hr_org_chart,l10n_gcc_invoice_stock_account,mail,point_of_sale,
purchase,website,website_sale,website_sale_autocomplete,
website_slides_survey
Some commit have added old Bootstrap 4 classes after the merge of
Bootstrap 5.
Note that it's not possible anymore as the merge bot is now able to
detect it.
closesodoo/odoo#98349
Related: odoo/enterprise#30551
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
Before this commit, the state selection field was positioned
on the left of the sheet, just above the title. Now, it is
positioned on the right of sheet.
This commit also fixes the text displayed by this field by
using the value of the fields (normal;blocked;done)_legend.
Finally, this commit removes the last uses of the deprecated
field `kanban_state_selection`.
closesodoo/odoo#97765
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit completes the style of the tags of m2m_tags field.
Tags did not have correct colors and had border.
The commit also fixes the m2m_tags_avatar field for the same reason
as well as a traceback when clicking on the remove tag button.
closesodoo/odoo#96654
Related: odoo/enterprise#30012
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
# Before this commit
Serializing a date would apply the TZ offset of
the luxon's DateTime object in which it is contained.
This sometimes led to output the wrong date.
# After this commit
Serializing a date contained in a luxon's DateTime object
will not apply any TZ offset and will output a serialized version as-is.
# Note
If you still want to apply the TZ offset, you should do it manually:
const toSerialize = date.setZone("utc");
const value = serializeDateTime(toSerialize);
closesodoo/odoo#98194
Related: odoo/enterprise#30469
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
There were 2 problems before this commit:
1. When switching view and coming back from the breadcrumbs: the
previous view props (such as the pager props) were lost;
2. When paging to the next record, switching view and coming back from
the breadcrumb, the view was reverted to the first selected record,
effectively ignoring the paging step.
This commit fixes both of these issues by keeping the controller's
props during a "restore" action, and by also updating the current
controller's props when using the pager.
closesodoo/odoo#97395
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit fixes the style of the field broken
since the introduction of the "display: contents"
rule in css.
closesodoo/odoo#97906
Related: odoo/enterprise#30073
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps:
- Go to Employees/Reporting/skills
The first group has a Level Progress of `0.84444` which is not a valid
percentage, it should be `84.44%`
This fix calls the correct format function to display correctly the
aggregate values depending on their widget or type instead of just
displaying the raw aggregate value.
(https://pad.odoo.com/p/wowl_views:
[GMF] Employee : Skills report, group sum should be % https://tinyurl.com/262ec37z)
closesodoo/odoo#98207
Signed-off-by: FrancoisGe <fge@odoo.com>
Inside a res.config.settings form view have a label with a string on it placed
before the field it is linked to.
i.e.:
```
<label for="myField" string="myString" />
<field name="myField" />
````
Before this commit, the string was not taken into account to build the HTML label.
After this commit, it is.
closesodoo/odoo#98109
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit fixes the recently converted color_picker field
widget. It is now always opened in a list as in legacy,
no longer togglable and many style issues have been fixed.
In form views, we still toggle the opened state because
always edit is coming and it would bloat the UI to
keep it always open.
Tests has been added/modified to assert those desired
behaviors.
closesodoo/odoo#97872
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Have a domain declared somewhere in the XML as:
`("&", ("field", "=", "value"), ("field2", "=", "value2"))`
Before this commit, that expression made the Domain algorithm crash, because tuples
were not allowed.
After this commit, only tuples containing at least one other tuple and some optional strings are accepted.
closesodoo/odoo#97850
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
Pass the options: `{'create': False}` to the a many2many_tags field in some arch
Before this commit, there was a crash because the API of the field's props did not
account for that use case.
After this commit, it does.
closesodoo/odoo#98050
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, in a form view in edition, if you clicked a toggle
boolean in an X2many, the view was saved. A toggle boolean should not do
a save if the main view is in edit mode.
The solution is to save the record only if the view's root datapoint
is in edition.
How to reproduce:
- Go to a form view in edit mode with an X2many that contains a toggle
boolean field.
- Click on the toggle boolean in the x2many
Result before:
The view is saved.
Result after:
The view is not saved and is still in edit mode.
closesodoo/odoo#97673
Signed-off-by: Samuel Degueldre <sad@odoo.com>
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>
Since the new views, the empty domains on the archs were not be taking
into account.
Now, the empty domains are taken into account, this was the legacy
behaviour
closesodoo/odoo#97791
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a section of a settings view that can be search in.
Have a dynamic invisble modifier (governed by a domain) on it.
Before this commit, the condition were just juxtaposed, which will cause problem
if one of them contains a "OR" operator. So, sections that should have been invisible were visible
because the if looked like: search() or search_other() and isVisible().
After this commit, the t-ifs are correctly combined so that they look like:
(search() or search_other()) and isVisible().
closesodoo/odoo#97811
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Have a field declared in python with a "help" property.
Put that field in a view with a "help" attribute.
Before this commit, the xml declaration was not taken into account.
After this commit, xml declaration has precedence over the python one.
closesodoo/odoo#97782
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a one2many in a form view. It displays its records with a kanban.
Add a record, now click on that new record.
Before this commit, there was not "Remove" button, preventing to effectively
remove a new (virtual at this point) record from the one2many.
Aftet this commit, there is a remove button that effectively removes the
record from the one2many.
closesodoo/odoo#97775
Signed-off-by: FrancoisGe <fge@odoo.com>
The cumulative option on line chart is useful for displaying
cumulative information graphically.
closesodoo/odoo#97394
Task-id: 2146487
Signed-off-by: FrancoisGe <fge@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>
Fixup for 4caa9596bc, where a rebase went bad.
Have a translatable field in a form view.
Create a new record with that form view.
Click on the button to open translations for that field.
Before this commit, the record was not before opening the translation dialog, hence
changing the translations could not work properly.
After this commit, this feature is back, and we ask to save a new record before
opening the translation dialog.
closesodoo/odoo#97824
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, it was impossible to correctly save a record
containing an invisible required field in its template.
Problem:
When a record tries to be saved or switched to readonly, it will check
the validity of all its fields and if any of them are invalid, it will
cancel the save or switch to readonly. In our case, we have an invisible
required field. If this field is invalid, it is impossible for the user
to modify it because it is invisible. So he cannot make it valid. So it
is not possible to save this record or to switch it to readonly mode.
Solution:
We no longer check the validity of invisible fields.
How to reproduce:
- Go into a list view with a template containing a field that is
invisible and required
- Click on Create
- Click on Save after editing the record
Before this commit:
The record doesn't save itself and doesn't go into readonly mode
After this commit:
The record is saved and in readonly mode
We have the same problem in the form view.
closesodoo/odoo#97610
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, in a touch device the behaviour was a
"tap-hold-to-show” which let the user see the Tooltip by pressing the
element, and letting it disappear when the pressure ends.
This commit allows choosing between the previous "tap-hold-to-show"
behaviour and a new "tap-to-show" which let the user see the Tooltip by
pressing the element, and keep it open until it press something else.
This behaviour is more adapted when the tooltip is on a specific icon,
as is the case for the labels, since : f981c5f8f0closesodoo/odoo#97680
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, images' url where just built upon the record's id and model.
Since the browser caches GET requests by url, the same record would always have the same image url.
Hence it appeared that when changing a record's image in form view, and going back
to the kanban, the image displayed was the old one.
A good enough approximation to solve this (and was actually solved in legacy code), is to use
the record's __last_update field, which basically tells the browser to re-fetch
a record's image when then record go through any modification.
After this commit, images are correctly updated in kanban and form views.
closesodoo/odoo#97544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, modifiers containing conditions on the `id`
field weren't always correctly evaluated in form views. This
happened on new records, when the `id` field wasn't present in
the view. In this case, its value in the evalContext was
`undefined`, so a domain like `("id", "!=", "False")` was always
evaluated to true. The `id` field is handled a bit differently
than the other ones, as we do not require for the field to be
present to use it in modifiers (mostly because we don't need it
to be present to know its value).
This commit fixes the issue by forcing a `false` value for `id`
when the record has no id yet.
closesodoo/odoo#97587
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, if the header of a column (X2many/ListView) has the
focus, a record is being edited and a key is pressed, then a crash is
displayed.
closesodoo/odoo#97559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a color field with an onchange on it.
Change the color.
Before this commit, the onchange was not passed to the server. This was
due to the internal of ColorField, which refreshed its value to the old one
even before owl or odoo did anything.
After this commit, the call to onchange is correctly passed.
closesodoo/odoo#97476
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Spawn a form view with a record and set its props "mode" to readonly.
Click on "Create".
Before this commit, the new record was in readonly mode.
This is never what we want, we always want a new record to open
in edit mode.
After this commit, the new record is in edit mode.
closesodoo/odoo#97451
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when the kanban view is grouped by m2o field, the
columns can be resequence by doing a drag and drop on one of them. In
some cases, this resequence should be disabled to keep the order of the
columns in the kanban view. For instance, in the project sharing
feature, the views are accessible by the portal users to easily follow
the tasks in the project shared but the actions allowed to the portal
user are restricted to only one model (that is `project.task` model).
So, in that case, the order of the columns should always be the same.
To avoid doing a customization code to be able to prevent the
resequence of columns in the kanban view, this commit adds a new option
in the kanban view called `groups_draggable`. By default, this option
will be true to allow the user to resequence the kanban columns
(if the field used for the group by is a m2o and not readonly).
If the option is false then the resequence of the kanban columns will
be disabled.
task-2941335
closesodoo/odoo#97447
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the parameter sent to the legacy fields were
different if the field was used on the form view, or on the kanban/list
view. Specifically, the attrs were not sent when the field was use on
the form view, and the viewType was not send when the field was use on
the kanban/list view.
Now, we standardize the parameters sent to the legacy fields regardless
of the view they are used on.
closesodoo/odoo#97431
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the QUnit test suite, we have cleanup code that runs after each
test to ensure that event listeners, setTimeouts... registered
during a test are removed. This is particularly useful for services,
as they do not have a "destroy" function to cleanup those handlers
they would have registered at startup. Side note: they don't
because it would only be useful for tests, as a service lives
forever in the prod environment.
Before this commit, that cleanup code didn't remove callbacks
registered with a setInterval. Moreover, we didn't remove event
handlers bound on document.body either. As a consequence, there
were memory leaks in the test suite (e.g. callbacks of the tooltip
service), and some crashes could occur if the user interacted with
the window after test completion.
closesodoo/odoo#97100
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the new views in owl, we wrapped every field in a div with the
class o_field_widget. This is a good thing in general, but it has the
issue that before this commit, the display property was set to
inline-block, in all cases.
With this commit, we set it to 'contents', which means that it will
simply get the correct display value from its content.
Part-of: odoo/odoo#96865
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
The mock of sendone/many was relying on the bus_service. Since owl.Component.env
is changing during tests setup, the bus_service was not always defined. In order
to make this more reliable, the longpolling/poll route is now mocked, returning a
promise that can be resolved by the sendone/many methods.
closesodoo/odoo#97298
Related: odoo/enterprise#30059
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
Allow commands in the command palette to be opened in a new tab by
either CTRL+clicking on the command, CTRL+ENTER or right clicking and
copying the link/opening in new tab.
Specifications
=============
Add new slot `focusMessage` that displays the message (if device is not
a mobile device). The `href` value has then to be defined in the
registry.
Task-2710445
Part-of: odoo/odoo#94241
- Less Overwhelming: reduces the hover zone to an icon. Tooltip
appearances are less intrusive as you move the mouse in the screen
- More discoverable: show an icon for the fields that have a tooltip
- better UX: max-width on the popup
closesodoo/odoo#97440
Note: commit 3363e55cac reduced help messages to useful ones.
Signed-off-by: Aaron Bohy (aab) <aab@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>
Before this commit, when the autofocus is used on an input with
`type="number", the `selectionEnd` is not available because the input
element's type ('number') does not support selection.
This commit checks the input type is not a number:
- if it is the case then the selection is used to place the cursor at
the end of the input content,
- otherwise the selection properties are not used and the input is
simply focused.
closesodoo/odoo#97466
X-original-commit: 38a5de7b2962a47c29b23f12f2ea7599bdea11fd
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, in a list view with a record being edited, if you
click on the header of a column sortable and press a key then a
crash is displayed.
Solution:
We will unselect the record when we click on a column header
(sortable or not). It will be impossible to focus the header of a column
when a record is in edit mode. Either the record is in readonly mode,
or it is invalid and the invalid field is focused.
How to reproduce:
- Go to a list view
- Switch a record to edit mode
- Click on the header of an sortable column
- Press a key (for example "a")
Before:
Crash is displayed, the record is still in edition and the header
of the column is focused.
After:
When you click on the header, the record switches to readonly mode
and the header of the column is not focused.
closesodoo/odoo#97433
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On the res.config.settings form view, click on button that will do an action
e.g. defined as some flavor of `<button type="object" name="myMethod" />`
Before this commit, this did not work as we never fully created the res.config.settings record in python
hence, when executing myMethod on the model res.config.settings, the ID was unset, pointing to no record.
After this commit, we "create" in python the transient res.config.settings record before doing anything.
closesodoo/odoo#97428
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Changed specialData (as in statusbar) were not discarded when clicking "Discard".
Now, when a form is Discarded, the specialData is restored.
Example: In project.task form view, there is a statusbar in which the domain depends on the project_id.
Edit a task, remove the project and the statusbar is updated. When discarding, the statusbar
is not restored to his initial state. Now it is restored to his initial state.
task_id: 2811530
closesodoo/odoo#97164
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Samuel Degueldre