A field input always asks for a record update when it is the target of
a "change" event but such an event might occur after some keyboard
events (e.g. a "Enter"). In order to make keyboard navigation work, it
is necessary to make a dirty field communicate its new value before a
change event and make sure the record is correctly updated before being
saved.
Before this commit, this was done via a system based on a special event
triggered on the model each time a record is saved but that solution was
not appropriate:
- the updates done in that way were not correctly awaited.
- they would be asked for even if the save would not be the result of
a keyboard event.
Here we replace the old system by a simpler one that works. When some
specific keyboard events occur, a dirty field ask for an update that is
correctly awaited.
closesodoo/odoo#96101
Related: odoo/enterprise#29873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When rewriting the Form view, we wanted the keyboard navigation using
"tab" and "shift+tab" to use the native browser behaviour. The purpose
of this commit is to remove the custom behaviour of X2many in a
form view when a "tab" or "shift-tab" make it be focused.
Before this commit, a new empty line would be created automatically.
After this commit, the button "Add a line" takes focus but no new line
is created.
If one wants to add one, that can be done by pressing "Enter".
Part-of: odoo/odoo#96101
In this commit, we improve some tests by making them use the util
function "editInput". Indeed those tests were incorrectly reflecting
the edition of an input: normally, change the value of an input should
trigger an "input" event.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode with a handle
field, if you passed a record in edit mode, the handle field was focused.
The expected behaviour is to focus the first editable field.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode, creating two
valid records in succession by pressing Enter caused the first record
in the list to go into edit mode. The expected behavior is to add a new
empty line.
How to reproduce:
- Create a first valid record
- Press the enter key to validate it and a new line is created
- Complete this new line in a valid way
- Press the enter key to validate it
Result before the commit:
The first record switched to edit mode and there is no new empty line.
Result after this commit:
A new blank line is created in edit mode.
If you press enter again the empty line is validated and a new line is
created.
Part-of: odoo/odoo#96101
Before this commit, in an x2many in list mode, it was possible to switch
several records to edit mode.
Normally, it is not possible to have more than one record in edit mode
in a list mode X2many.
How to reproduce:
- Have an X2many with at least two record already.
- Modify a field of the first line and make it invalid
- Click on the second record
Result before the commit:
Both records will be in edit mode.
Result after the commit:
The invalid record stays in edit mode and the other record stays in
readonly mode.
Part-of: odoo/odoo#96101
Previously, attempting to add a class to a button box would crash
because the button box divs are compiled to ButtonBox component which
did not accept a class prop. This commit fixes that.
closesodoo/odoo#96726
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the conversion of views to the new webclient, the o_xxl_formview
class was no longer applied as expected, which broke the layout and the
width calculation in embedded list views (as the chatter would take up
more space than intended during the width computation). This commit
fixes that by adding the class when needed.
This commit also moves the css rules relative to that class which are
mainly used for the side-chatter, from enterprise to community, as the
side chatter has been made available in community as well.
closesodoo/odoo#96627
Enterprise: odoo/enterprise#29803
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the records created in grouped kanban view via
the quick create feature were displayed in the bottom of the column
where they had been created. They should be on top. This commit
fixes that issue. Note that this only concerns the state of the
kanban view before the next reload, as from that moment onwards,
the default order on the model is used.
Issue introduced by the conversion of the kanban view to owl.
closesodoo/odoo#96606
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit fixes the wrong implementation of the
field. It was not functional and is now using the
FileInput component.
Before the commit, it was not possible to upload or
delete files from the list. Test has been adapted to
those changes.
Toast notifications were also missing, and a new
test has been added to check that a notification is
correctly displayed when the server responds with a
error message for a given file.
Part-of: odoo/odoo#96357
In SearchModel, the calls to search_panel_select_range and
search_panel_select_multi_range were done without using the global
context (e.g. the action context), contrarily to what is done in the
legacy SearchPanelModelExtension. We fix that.
closesodoo/odoo#96458
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a legacy list view, click on a record to open it in a new (WOWL) form view
Before this commit, the pager was wrong, as we never passed the list's current resIds
to the form.
After this commit, the pager of the wowl form view is correct.
closesodoo/odoo#96123
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit solves 2 problems in the list view:
- incorrect label for a column
- the label in the optional column dropdown can be different than
the label of the displayed column
When converting the list view, we used the displayName of the widget
and not its label.
In order to improve the consistency between the labels in the optional
column dropdown and the associated columns, we decided to use the same
label.
closesodoo/odoo#96408
Signed-off-by: Aaron Bohy (aab) <aab@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>
The view mode in which to display a legacy x2many field in a new form
view was badly processed. This lead those fields to be not renderered at
all (no list or kanban renderer displayed) or be renderered with the
wrong renderer in mobile mode. We fix that.
Part-of: odoo/odoo#78221
Sometimes a field component might need to know some other fields values
to render itself or for other purposes. In legacy, a mechanism allowing
to load some field values not displayed was available: a field would
declare a fieldDependencies object specifying some field names and
their types and the related values would be loaded along the other data.
Here we introduce the same mechanism for the new views.
Note that in a new view list, the tag widget is not currently supported
so that we have remove some lines in the list arch parser that were
useless.
Part-of: odoo/odoo#78221
Before this commit, if an arch contained a tree which itself contained
a tree, the parser would crash.
The reason for this crash is that the parser was trying to parse the
second tree with the model of the first. So it didn't know the fields.
The solution is to stop the exploration of children when it is not
necessary. For example, for fields, it is not necessary to explore
the children, it is parseFieldNode that takes care of it.
Part-of: odoo/odoo#78221
This rev allows the function built by the useViewButtons hook to take
a beforeExecute callback at call time, in addition to the existing
beforeExecuteAction callback that we can pass to the hook, at the
function's build time.
The rationale for this is to allow any caller to prevent the execution
of the action represented by the clickParams at the call level. It is
useful to check if a user is allowed business-wise to execute an action.
Part-of: odoo/odoo#78221
Previously, the statusbar field didn't display the currently selected
value for selection field in mobile, as the getter to compute the name
of the currently selected item only accounted for the many2one case but
not for the selection field case.
This commit adds handling for the selection field case and a test for
it.
Part-of: odoo/odoo#78221
The goal of this commit is to allow an X2m in list mode with a custom
controller to use the controller context when creating a new line with
a 'tab' keydown.
Part-of: odoo/odoo#78221
This commit adds the ability to set a class on a list view.
This class will be added at the same level as "o_list_renderer".
For example:
<tree class="myClass">
...
</tree>
Part-of: odoo/odoo#78221
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Previously, if a label for a field had an invisible attr which should
cause it to be invisible, and it was not at the top-level of a group, it
would be rendered even when it shouldn't. This was caused by the fact
that when we compile the form arch, we don't copy the t-if attribute
from the original label when generating the FormLabel component.
This happens to work when the label is at the top level of a group,
because when compiling a group, if anything at the top-level of a group
has a t-if, we move it from the node itself to the t-set-slot that gets
generated for the FormGroup component before we would generate the
FormLabel.
Part-of: odoo/odoo#78221
Before this commit, the More dropdown button of the ButtonBox
(which displays stat buttons) was broken i.e. the more button
was on another line because its size was wrongly set.
After this commit, the style is corrected, every button of the Box
is on the same line.
Part-of: odoo/odoo#78221
Before this commit, when the status bar did not have buttons to display
it was not displayed at all.
After this commit, we display it even if there are not any button inside.
Part-of: odoo/odoo#78221
Before this commit, the header declared in a form's arch was not injected
at the right place.
After this commit, the header's elements are put as children of the sheet_bg element
if present.
Part-of: odoo/odoo#78221
Before this commit, adding a component in the main component registry
after the initial mount did not work that is, the MainComponentContainer
never rendered the new component.
After this commit, adding a component to the registry works as expected.
Part-of: odoo/odoo#78221
Before that commit a zero value for a monetary field would be wrongly
considered invalid. This would block many flows (e.g. a save).
Part-of: odoo/odoo#78221
Before this commit, the ace editor crashed when switching to edit mode or
when clicking in it.
After this commit, it works as expected.
Part-of: odoo/odoo#78221
Before this commit, the List and Kanban views did not allow the use of
a Banner without adding it in the View definition.
Like this:
```
export const listView = {
...
Banner: OnboardingBanner,
...
}
```
Now, we use by default OnboardingBanner as Banner if no other has been
defined in the View definition.
closesodoo/odoo#95945
Related: odoo/enterprise#29452
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, it was not possible to hide the 'Add Custom Group'.
This commit adds this feature and associated tests. Hiding this menu entry
can now be performed by adding `hideCustomGroupBy: false` in the `View`.
This commit also uses `MAPPING` values in the components assignment of
`ControlPanel` in order to improve code maintenance.
task-2845729
Have an editable list, select a record, click either on a group header or on the list header
press the arrow down key.
Before this commit, there was a crash because we attempted at navigating with the keyboard inside the list from
a wrong entry point. The crash occured because no record was selected.
After this commit, when clicking on something else than a data row or a column that is sortable
we unselect the record. Hence there is no crash when navigating with the keyboard
closesodoo/odoo#96233
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Previously, the useService hook would call _protectMethod, which wraps
async methods so that any call to them after the component has been
destroyed throws an error, and any call that was started while the
component was alive but returned after the component was destroyed would
return a pending promise such that no more component code is executed.
In doing so, it would for some reason bind all the methods to the
service, this prevents some functionalities where a method would return
a differently configured version of that same service, on which you can
call the methods again (eg: orm.silent), as the modified service's
methods would not be bound to that modified service.
This commit fixes this issue by not binding the methods eagerly, and
introduces a test for all these behaviours.
closesodoo/odoo#96121
X-original-commit: 518a93a5487f62bd9b460412d4775cd0ac80a262
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Port of legacy's BasicRenderer for WOWL views.
In a nutshell: Tooltips are problematic in touch devices as they are
meant to appear on hover... which doesn't happen with touch events.
This commit implements a "tap-to-show" behavior which let the user see
the Tooltip by pressing the element, and letting it disappear when the
pressure ends.
Part-of: odoo/odoo#95924
The legacy ProgressBar could receive a title in props that it had to
display.
In this commit, we add support for the title props in the new
ProgressBard field.
closesodoo/odoo#95922
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Doing a `search_count` on millions of records could be very slow. On
large databases, the pager counter "1-80 / 8000000" could take several
seconds just to get the total number of records.
This commit limits the counter in list and kanban views to 10k records,
and shows "1-80 / 10000+" if the limit is reached. If you click on
10000+, it updates with the real count (or if you go up to 10000 with
pager or input value).
The search_count on res.partner of odoo.com takes 4s. With this patch,
it will take ~20ms.
Task 2761165
closesodoo/odoo#95642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
The new implementation of float field has some problems dealing with
external changes that would impact it. The specs are changed to format
on blur. It was overly complicated not to as the behavior of all input
fields are controlled through the input field hook.
Note: in the past, formatting would only occur after a save action, now
the formatting is on blur.
The input field hook had some issues dealing with invalid and dirty data
so this has been fixed as well.
closesodoo/odoo#95364
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When unselecting an export template, the list was empty
instead of just keeping the current list. I also added
some tests for this component introduced in Owl recently.
Some scss changes have been done to remove unnecessary
lines from the file and fix the style in a small window.
With a small window, items from the export list are not
draggable and the list must be placed at the bottom
part of the dialog
closesodoo/odoo#95226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, we asserted that the view did not switch to form when clicking
on the the color picker. It was wrong because there is no action manager, hence no possibility
to effectively switch view.
After this commit, we assert that the list view's callback selectRecord is not called, which
is equivalent.
closesodoo/odoo#96159
Signed-off-by: Aaron Bohy (aab) <aab@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>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, it happened that the domain selector
couldn't find the operator linked to the field.
This commit adds a fallback on the existing operators
to find an operator that matches.
for example the domain `[["name", "like", "M"]]` gave
`Name ? "M"`, now it correctly gives `Name like "M"`.
closesodoo/odoo#95891
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In legacy, the domain field had an `in_dialog` option that was
used to display a button that opens a dialog to edit the value.
This commit reimplements the `DomainSelectorDialog` in owl
and adds the option the new domain field.
closesodoo/odoo#95768
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
FrancoisGe