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>
This commit removes most of the calls to checkValidity outside of the
(Basic)RelationalModel.
The validity checks in ListRenderer were not useful
because the operations done after them (like a switchMode) would make
a validitity check and the expected goal would be achieve in any case.
Part-of: odoo/odoo#96101
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>
Since odoo/odoo@2dd37982e6 , Kanban
column's width is flex based. But sadly two types of columns were not
adapted properly:
- Kanban small column didn't reduce the column width
- Quick create kanban column shrinked too much
This commit fixes both these issues by properly setting the flex-basis
size for one and disabling shrinking for the other.
closesodoo/odoo#96650
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>
As the `color-contrast` function provided by BS5 basically fulfill the
same need as the custom `o-get-most-contrast` function and the later one
isn't used, we can safely remove the custom one.
closesodoo/odoo#96626
Note: last (and only) usage was in mrp_workorder's tablet view.
Related: odoo/enterprise#29802
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit refactors the way we handle the "<>" case in domain
evaluation, for the sake of consistency with the "==" case. Indeed,
we tried to avoid using JSON.stringify as it could have an unwanted
behavior (e.g. it could crash, or it could have been overridden on
the value we manipulate).
closesodoo/odoo#96614
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since the revamp of the Kanban View in mobile and the migration of the
Settings view to the OWL views, the jQuery.touchSwipe library is not
used anymore.
closesodoo/odoo#96608
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>
The purpose of this component was not helpfull
as it has no real use case and was only used
by the BinaryField component.
Instead of using an entire component, we only
keep the DOM that is now used directly in the
BinaryField template.
closesodoo/odoo#96357
Signed-off-by: Aaron Bohy (aab) <aab@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>
During the BS5 migration, the .text-body class wasn't properly ported.
As it is a standard Bootstrap class and useful to override component's color with the one used by the body (ie. set a heading color the same as the content).
This commit restores it.
closesodoo/odoo#96173
Signed-off-by: Pierre Paridans (app) <app@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>
Previously, we were using the bootstrap 4 function "color-yiq" to choose
a text color depending on the background color. Since the migration to
BS5, color-yiq is no longer valid, and color-contrast should be used
instead, but the wowl-views migration was maintained in parallel from
the BS5 migration and some instance of this function call were added
back with it. This commit fixes those.
Functionally, this fixes the text color in the m2m_tags field.
closesodoo/odoo#96598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
These rules no longer apply because they use a direct descendant
selector which no longer matches since field widgets now have an extra
div. These rules also already exist in the statusbar_field.scss file.
Part-of: odoo/odoo#96598
After the bootstrap migration, the enterprise badge in the settings view
were the wrong color because the class bg-primary was not adapted. This
commit fixes that.
After the wowl views merge, the badge has become hidden behind the
navbar, because it can no longer modify the DOM of its label as it is
managed by owl. When there is no label, the widget appends the badge to
its own $el, and uses position: absolute to position it. This didn't
work because the closest parent that was positioned was the view itself.
This commit fixes that by giving a position: relative to the settings
box.
closesodoo/odoo#96580
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The css rules for the settings view should be in the corresponding css
file, not with the generic form view rules. This commit moves these
rules to the proper files and unnests some rules when the selectors are
specific enough, which generates less CSS.
Part-of: odoo/odoo#96580
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>
Before this commit, the evaluation of the context was done for all
the context, even when only a subset of the context was needed.
Now, we evaluate only the attributes of the context that are used.
Part-of: odoo/odoo#78221
The `toPyDict` method is used to transform an object into a "python" dictionary,
by returning an equivalent object with the PY_DICT object in the prototype chain.
In practice, it is called everytime we create an evaluation context.
This is a performance problem, since creating the context is not cheap in the
case of Odoo form views: we need to iterate on all the values of the current
record, checking for each changes, applying all relational operations, ...
And even worse, almost all of the domains that we need to evaluate have very
simple conditions, which just needs to check the value of one field. So, it is
useful to make the computation of the eval context keys lazy, and this commit
make sure that pyjs does not undo the lazyness of the eval context, if any.
Part-of: odoo/odoo#78221
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
Previously, legacy many2one fields and their extensions in new views
were unable to quick create records, this is because the compatibility
layer between the legacy fields and the relational/basic_relational
model is incomplete. This commit adds code to handle this specific case
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
This commit defines a "displayOptionalFields" getter that can be
overriden to force the presence of the optional column dropdown.
For instance, this is necessary in enterprise to add an item to
promote Studio.
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>
Before this commit, legacy fields spawned in wowl views didn't
receive the correct "mode" and "hasReadonlyModifier" params. They
do now.
We do not add qunit tests for this, as tours already identified the
issues, and it only concerns legacy fields that we'll soon remove
anyway.
Part-of: odoo/odoo#78221
Have an editable list view with a legacy many2one field (for instance,
an extension that hasn't been converted to wowl yet). Before this
commit, the edited row was unselected when the user clicked in the
many2one dropdown to select a value. The reason is that legacy
many2ones use jQuery autocomplete, that puts the dropdown directly in
the body, which is obviously not inside the table.
We do not add a qunit test for this, as it only concerns legacy
fields that are about to be removed, and it is tested in tours
anyway.
Part-of: odoo/odoo#78221
Before this commit, when there were more than one action menu (in
a list or form view), e.g. "Print" and "Actions", they weren't
displayed in the same line.
Part-of: odoo/odoo#78221
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
The form view is styled differently on small screens, and those rules
are based on the presence of the "o_xxs_form_view" className. This
commit correctly toggles it.
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
It might happen that one wants to spawn a FormViewDialog with a
view that has a js_class, and the corresponding js code hasn't
been converted to owl yet (it is still an extension of the legacy
FormView). Before this commit, when that happened, the control
panel buttons of the form view weren't moved to the footer of the
dialog, because this isn't supported with legacy views. This
commit is a workaround, as it fallbacks on the legacy FormViewDialog
in this situation.
Without this commit, the main flow tour fails.
Part-of: odoo/odoo#78221
FrancoisGe