In html, tags are case-insensitive. However, owl templates aren't,
as nodes starting with a capital letter are considered as component
nodes (not html). This means that people can use capital letters in
form or kanban archs for html nodes and it should work.
Before this commit, it didn't, because the compiler kept the case
when generating the owl templates. For instance, an arch like
`<form><Div/></form/>` produced the error 'Cannot find the
definition of component "Div"'. This commit fixes the issue.
Part-of: odoo/odoo#108221
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
Before this fix, the '.o_form_status_indicator' was in the right
part of the control panel.
But on desktop, we want it next to the last breadcrumb item
to cognitively attach the "save status" to the record name.
closesodoo/odoo#107397
Task-id: 3067691
X-original-commit: 24b098767b03c97ffe108a7f8aa0f77c08aecef5
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Purpose
=======
Prevents auto save of not dirty forms with
text fields on page reload and tab/browser closing.
Specifications
==============
The text field default value is making Odoo consider
the form as dirty even when it's not which triggers
auto saving for not dirty forms.
Change the text field widget setDirty condition to
prevent considering empty textarea string dirty.
Typically, if the previous value was false, false and
empty string should be considered as the same value.
Task-3031570
closesodoo/odoo#106619
X-original-commit: 787ef58dd3f91f829509f738ee40c8764c403757
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, we had an issue with the width calculated
for data cell (see. sizeOfDataCell).
In some case, the width was 50% instead of taking 100% of the
available space.
This was because some elements of the inner groups that should not
have been visible were computed as if they were, taking an effective
slot in an innergroup's row.
E.g. with two labels:
Before:
"invisible label" and "label" on the same line with `style="width: infinite"`
"data field" on a second line with `style="width: 50%"`
After this commit:
"label" and "data field" on the same line with `style="width: 100%"`
Note that as `infinite` is not a valid value, this wasn't interpreted and
style attribute was empty.
Thanks to grid for still aligning elements even if they are technically
in different rows. It's why we only saw this issue because of the
width of the data cell.
Steps to reproduce:
- Go to Accounting
- Customer -> Invoice
- Create a new invoice
-> See Customer field
Thx to @kebeclibre
closesodoo/odoo#105489
X-original-commit: e177c63e3618e4b9e492a27d1301c098a0066cb6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, when compiling a form group, the scope class is
added to the elements of the outer group. It was added on the element
class attribute. The issue is that FormLabel don't have a class
attribute but a className attribute. So the class wasn't shown on the
DOM.
Now, the class is added on the FormLabel className attribute and shown
in the DOM.
closesodoo/odoo#105315
X-original-commit: 214beb39d7c1a315255f0a5a842e60f73e7900cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.
This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.
Fixing #74647 (from 16.0 to master)
closesodoo/odoo#103572
X-original-commit: 95f8266a5b84f5faa59a713019ab713392b3ef78
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the code that wrapped legacy fields and widgets
(coming from the legacy registries) into owl components and added
them to the wowl registries. This temporary compatibility layer,
which was incomplete and only allowed us to merge the new views
without converting all fields/widgets in once without breaking
everything, is no longer necessary as we now have converted all of
them into owl components.
X-original-commit: 555959c87e25faa71396f61479e8bb41b66ac164
Part-of: odoo/odoo#102606
Do an action in target new that will spawn a record in its form view.
The typical example is "Edit View: XXX" in the debug systray.
On the dialog, click on "Discard".
Before this commit, that button did not close the dialog.
After this commit, that "Discard" button closes the dialog.
closesodoo/odoo#103275
X-original-commit: 08751e0eef0cefe74e626ffa8ba26a5e8f18113f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the basicRelationalModel could not handle the legacy
event "reload" trigger by the basicModel., resulting in crashes.
In particular, when the method "action_archived", via the method `record.archive()` returns an action
(in target new usually) to confirm or ask the user for some additional information, closing that modal
will trigger a model reload via the event.
After this commit, this whole flow is tested and works correctly.
closesodoo/odoo#102826
X-original-commit: 0abb90fb2aa7857990b5f5dae95e9e891125b5fa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the user was not notified when he
closed the tab or the browser while modifying a record.
Now, the user will be asked to confirm the close if there
is at least one invalid field.
task id: 2994132
closesodoo/odoo#102990
X-original-commit: 3fcc36786453f3006974f5fd0fa395ad5d07d9a2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Rationales:
- having a textual display "Unsaved changes" implied to the user that they
had to save
- having buttons "hiding" behind a hover effect on a span of text was
very unintuitive
- since we don't want an hover anymore, having text buttons would draw a
lot of attentions => use icons + tootltip instead
closes odoo/odoo#102757
Forward-port-of: #102605
Related: odoo/enterprise#32570
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Have a form view in a dialog (action in target=new)
The create/write of that model throws an error.
Before this commit, the "Oh snap!" dialog was displayed, but makes little sense
in a dialog.
After this commit, the old UserError dialog is displayed.
closesodoo/odoo#102764
X-original-commit: d36f1708219f63fae5a86b6c1e81b328ca96b347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an InnerGroup which has a first div visible all the time
and a second div conditionally invisible.
Before this commit, when the second div was invisible, the first was not
displayed.
After this commit, the two divs are displayed correctly.
X-original-commit: c69836e3c53e1efb61f66612c266a31aa9b54816
Part-of: odoo/odoo#102578
The purpose of this commit is to allow the restoration of open pages
in notebooks of a form view when switching view.
How to reproduce?
- Go to a form view with a notebook.
- Select a page in the notebook
- Go to another view
- Use the breadcrumb to go back to the previous form view
Before this commit:
The page opened in the notebook is the default one (the first one
or the autofocus one)
After this commit:
The page opened in the notebook is the one previously selected
closesodoo/odoo#102468
X-original-commit: 160c0347526612b6e6f93b8079eeb868d37d48f4
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
- Before this commit
Suppose that in a form view, there is an x2many list view
that would open a form view dialog when edited.
For the dialog to open, the concerned record is duplicated and
passed in props to a FormRenderer.
Now suppose that this form view dialog also has an x2many list
view rendered somewhere: the StaticList datapoint attached to
this list will have the same context as its parent.
This is not what we want because some of the keys of the context
does not make sense with the list's model.
In fact, it has led to tracebacks to be displayed in case of we want
to open a record of this list in another form view dialog.
- After this commit
When those lists are created, their context are cleared from
their parents' keys starting with "default_" or ending with "_view_ref".
closesodoo/odoo#102557
X-original-commit: 1ba468706295f651105ca3fc8aae477b4f05c28e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit fixes the behavior of the FormView in a dialog. Since the
view is only visible in edition, it is no longer necessary to keep the
dialog open after the save has been processed. If the save has been
successful, the dialog now closes as expected.
A test has been added to assert this behavior.
X-original-commit: 86f68fe072a50baf49b9a8cf06f9c1e2541756e3
Part-of: odoo/odoo#102522
This reverts commit 8d7bcc8eee7a333e8e463469177a1a86f9928254.
The fix also impact a lot of form views without a <sheet> node
(o_form_nosheet), e.g. Settings, Knowledge articles, Mass Mailing, Bank
Reconciliation, widget, etc.
Not the correct solution.
X-original-commit: 00e71f3ebad40d32f74f945475fb474e89b6cf4a
Part-of: odoo/odoo#102511
Previously, in form views without a sheet (eg in wizards), there would
be a scrollbar on the content. This is caused by the fact that
outer groups have gutters of size 5 in desktop which creates negative
margins on the row of 1.5rem which is 18px with the default size, but
the nosheet form view only has 16px of padding on the sides, causing the
groups to be 4 pixels too wide.
This commit fixes this by adding the correct padding classes on the
form view when it doesn't have a sheet.
closesodoo/odoo#102357
X-original-commit: 8d7bcc8eee7a333e8e463469177a1a86f9928254
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, a virtual record in form view always had the
o_form_dirty class, which is problematic when a tour ends with a virtual record.
After this commit, a virtual non-dirty record in form view doesn't have
the class o_form_dirty, and doesn't have the o_form_saved either as that doesn't make more sense.
closesodoo/odoo#102153
X-original-commit: 0041b9fd8eb75d5b680d94d491e2b9f684b2d0c1
Related: odoo/enterprise#32282
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a form arch containing
```
<notebook>
<page class="myClass" />
</notebook>
```
Before this commit, "myClass" did not appear in the final DOM.
After this commit, it does.
X-original-commit: e886adcb38695bcfa8a9f741d4e496229fb199ff
Part-of: odoo/odoo#102153
Before this commit, printing an invoice which is not
created yet reloaded the view with a new record.
Now, the view reloads with the current record.
closesodoo/odoo#101947
X-original-commit: 0bad6ae4185d9b25684d0c47c9cee7c098053707
Related: odoo/enterprise#32191
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the "Oh snap!" dialog could be displayed anytime
a server validation error was returned by an RPC. Also, clicking
on the "discard" button in this dialog always triggered an `historyBack`
even when we open a new action.
Now, this dialog is only opened on error while saving and does not
`historyBack` anymore.
closesodoo/odoo#101802
X-original-commit: 31c6ecb7f9ad68d337cbc7f0fd3b4d682c088b85
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In debug, we want to see the field component description in its
tooltip. For instance, for a many2one: `Widget: Many2one (many2one)`,
`Many2one` being the `displayName` attribute of the Component, and
`many2one` the key in the registry (to use with `widget="many2one"`
in archs).
X-original-commit: 39fbb4620b5e846cd597ecbbfefdbda8bc4cb8e1
Part-of: odoo/odoo#101787
This commit replaces the FormView group tables with css grids.
Part of the overall v16 SCSS optimization/restyle, task-2704984
task-2918464
X-original-commit: a2b894989ea33364dd29a7d412e4bd4260c1f5ef
Part-of: odoo/odoo#101655
Before this commit, if an invalid field was completed when editing
another field using an onchange, the field was always considered invalid.
It was not possible to save the record.
Why:
Fields modified by an onchange were not removed from the list of
invalid fields.
Solution:
Remove all fields modified by an onchange from the list of invalid fields.
How to reproduce:
- Create a new record in a form view with a required field
- Click on save (the required field appears as invalid)
- Edit another field that causes a change to the invalid field (onchange)
- Click on save
Before this commit:
The record is not saved and the required field is still invalid.
After this commit
The record is saved.
closesodoo/odoo#101343
X-original-commit: 46074244798d2e447f4e5cf174244ea263563b1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Make it possible to override both before and after execute actions on
all view controllers using `useViewButtons`.
This avoids having to change a value in the env to override the function
being called when clicking on a button.
closesodoo/odoo#101310
X-original-commit: 9f6c2b8e969635f35786d58ee89ca767ff57144d
Related: odoo/enterprise#31860
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, in a form view, discarding a record with an invalid
field containing an input does not restore the original value.
How to reproduce
- go to a form view with an integer field
- edit the integer field with an invalid value ("blabla")
- click outside the field (the field is displayed as invalid)
- click on the discard button
Before this commit:
The integer field always displays the invalid value.
After this commit:
The integer field displays the value before the edit.
closesodoo/odoo#101316
X-original-commit: f81e4019ca00953d9624557c98033aef46efc47a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, the data-hotkey attribute set on button nodes
in form views was ignored. This commit re-introduces the feature,
enabling the keynav on those buttons.
closesodoo/odoo#100563
Signed-off-by: Georis François (fge) <fge@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field or widget with fieldDependencies
(dependency on field A)
- in the arch, the x2many form view isn't inline
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, field A isn't present.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the activeFields,
since they are shared between the x2many list and form).
This commit fixes the issue by adding fieldDependencies not only
in activeFields, but also in fields if not already there.
[1] 4636620004closesodoo/odoo#100495
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Scenario:
Open a record that is invalid in database (a required field is
empty), and click on the pager to go to another record.
Before this commit, we prevented the user from leaving the record,
marked the field as invalid and displayed a notification. This is
a weird UX experiment, since the user changed nothing (he did not
even enter edit mode). In this situation, since the record hasn't
been modified, the user should be allowed to leave. This is how
the legacy form view behaved.
closesodoo/odoo#100442
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since [1], a call to getView no longer returns the all models the
list of all their fields, because a lot of them aren't necessary.
However, it caused an issue in the following situation:
- have a form view with an x2many displayed as a list
- in the list, have a field using the widget many2many_tags
along the color_field option
- in the arch, the x2many form view isn't inline
list must be present, without the color_field option,
and the color field must not be present,
- in readonly mode, the user clicks on a row, which will open
the x2many form view
- since the form view isn't inline, a call to getView is done
- in the returned form view, the color field isn't present,
the field using many2many_tags/color_field in the
list is present, and without the color_field option.
Since [1], it crashed at this point because A wasn't part of the
known fields in the form view (but it was in the fieldsInfo,
since they are shared between the x2many list and form).
This commit fixes the issue by adding the color field not only
in fieldsInfo, but also in fields.
[1] odoo/odoo@4636620004closesodoo/odoo#100479
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, on compiling the field, a search is done to find the
label to link to the field. To do this search, the following field's
attributes were used: the `id`, which is encoded on the arch of the
view; if the `id` wasn't set, the `field_id`, which is an internal
technical attribute, is used, and if neither of these were set, the
'name', which is also encoded on the arch, attribute is used. These
attributes are compared with the content of the `for` attribute on the
label.
The issue with this, is that as the `field_id` is an internal technical
attribute and could never be found on the view arch, neither on the
content of the `for` attribute on the label. Leading to empty labels, or
labels linked to the wrong fields. This principally occurs when two
fields with the same name are found on the view.
Now, only the `id` attribute and the `name` attribute, which both can be
found on the view arch, are going to be used to search the correct label
to link to it's corresponding fields.
closesodoo/odoo#99399
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Tooltips (and aria-label) should be used when the content of the element
is not self explanatory; but in the case of the create/save/edit buttons
available in several view control panels (kanban,list,form), tooltips
with dubious usefulness were added (e.g. "Create record" when you hover
on a button labeled "CREATE" is not really an information bomb).
Since these buttons tend to be used in tours, and the "coucouilles"
of the tours will also be some sort of tooltips, it means that you
can have frequent weird visual interactions between nunuts and stupid
tooltips.
This commit removes these stupid tooltips.
Feedback-2973374
closesodoo/odoo#100078
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In a form view, modify a record s.t. a required field is unset,
and then click on the pager to navigate to the next or previous
record. Before this commit, a notification was displayed (because
a required field is unset), but we switched to the other record
anyway.
This commit restores the desired behavior, which is to stay on the
current record to let the user fix it or discard it.
closesodoo/odoo#100050
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since owl now uses error chains/causes when errors happen in the owl
lifecycle, when an error happens in the owl lifecycle, the displayed
tracebacks generally only contain the stack trace of where owl called
the corresponding lifecycle hook.
This commit modifies the error service and the error utils so that now,
when completing/annotating a traceback, we also add the tracebacks
(annotated when appropriate) of the error cause chain, as it contains
valuable debugging information.
This commit also makes it so that the QUnit suite logs the source of
each test failure (which may be an error with a chained stack trace)
closesodoo/odoo#98157
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce:
- Go to Accounting > Configuration > Chart of account
- Click on the setup button on the "Current Assets" line
- items are not correctly aligned
Cause of the issue:
`<separator/>` should take an entire row
The separator was on the same row as the field label.
closesodoo/odoo#99641
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit moves the element inside the table to avoid that the
dropdown may overlap thead column labels.
Part of the overall v16 SCSS optimization/restyle, task-2704984
task-2946835
Part-of: odoo/odoo#98234
Aaron Bohy