The CompoundDomain class allows to regroup several domains with an
implicit "AND"; these domains can be either a string, an array or
another CompoundDomain. A CompoundDomain can then be converted to
an array thanks to pyeval.js.
For example, if a CompoundDomain is initialized with `[A, B]` and
`[C]`, the array conversion gave `[A, B, C]` (which is expected).
However, a hackish method was used with CompoundDomain. If one of the
domain of a CompoundDomain is equal to `["|"]` (an array with the
OR operator in it), the two next subdomains were supposed to be joined
by a OR operator. Indeed, for the case of a CompoundDomain initialized
with `["|"]`, `[A]` and `[B]`, the array conversion gave `["|", A, B]`
(which is expected). However, if initialized with `["|"]`, `[A, B]` and
`[C]`, the array conversion gave `["|", A, B, C]` which is very wrong
as what was expected is `["|", "&", A, B, C]`. The problem is that the
given `[A, B]` contains implicit "&" operators.
This commit fixes the problem by normalizing only if the CompoundDomain
starts with a ["|"] or ["!"] array which is the standard odoo case.
This allows to limit breaking custom code (e.g we want a simple "AND"
of `[A]` and `[B]` to stay `[A, B]`, not become `["&", A, B]`).
The commit also modifies a test so that it checks that the problem is
properly solved.
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
note: already present in 10.0 (with a test) as f65475d68
When an input is saved with an invalid value, it gets the
`o_form_invalid` class. This makes the border red. In enterprise, there
was a bug as required inputs have also a different border color and the
rule was more important. Unfortunately there is no avoiding
the !important rule here. Indeed, other solutions would require to make
more rules in enterprise or to change the order of files (which would
create many problems).
To reproduce:
- Get a slow connection, e.g. activate throttling in debug mode of the
browser.
- Create an invoice with at least one tax.
- Change a price unit.
- Click on 'Save' then repeatedly on 'Validate'
The tax lines are duplicated.
The issue comes from two identical `write` calls whose purpose is to
delete the existing tax line and create a new tax line.
The two calls are issued by the click on 'Save' and the click on
'Validate', which triggers a 'Save' since it doesn't consider the form
as being saved yet.
There were several issues:
- The buttons from the statusbar were not disabled
- The buttons were enabled too soon. They should be enabled again when
the form is reloaded, otherwise the call to 'Validate' doesn't
consider the form saved.
This is an extension of commit
https://github.com/odoo/odoo/commit/bbbf3db581b5cf883
opw-710642
Forward-port of https://github.com/odoo/enterprise/commit/8a55b3f9f7a7524583effb8198c03ebf695131bd
There are multiple problems with the editable view list. It should be
solved once and for all in the work-in-progress master.
This commit fixes a bug with readonly checkboxes. When a field is
readonly, the table cell gets the "o_readonly" class which changes
its style and behavior. When entering edition, the cells are hidden
except the ones with this "o_readonly" class so that their style are
not affected. The "o_readonly" cell content however was hidden thanks
to a "color: transparent;" rule to let the form readonly field show
the value. The problem is that checkboxes... are not hidden with this
"color: transparent;" rule. Also, the "o_readonly" class is not toggled
during edition while the readonly status could be... so the right fix
would be to get rid of this "o_readonly" class and let the inline form
handle the behavior, but this would affect style and possibly break
unknown behavior.
This fix adds rules to handle the checkbox case correctly.
Steps to reproduce:
Go to any pivot view (for example Sales > Report > Sales) and add
the current view to your personnal dashboard (in the search view: Favourites > Add to my Dashboard)
Go to the dashboard, traceback because $buttons was not defined.
opw:707296
Steps to reproduce:
Go to any pivot view (for example Sales > Report > Sales) and add
the current view to your personnal dashboard (in the search view: Favourites > Add to my Dashboard)
Go to the dashboard, traceback because $buttons was not defined.
opw:707296
Before this commit, when saving the pivot state in a favorite filter,
then restoring it, the row groupbys were ignored. This commit makes
sure that we take them into account if necessary.
Before this commit, when changing measures from the favorites menu (by
selecting a filter with some pivot_measures), the measures in the
dropdown menus were not correctly updated.
This commits make sure that we update the active measures in the menu after
each changes coming from a do_search.
Modern browser implement the autofill specs as described at
https://html.spec.whatwg.org/multipage/forms.html#autofill
This means that there is now a way to tell the browser when a password
field is supposed to be filled with the user's own password (e.g. on a
login field), and when it's supposed to be used to input a new secret
value (e.g. when changing someone else's password).
This can be distinguished by setting the autocomplete attribute
to `current-password` or `new-password`.
In addition, many browsers have decided to entirely disregard the
autocomplete='off' attribute value, because it is felt that using
a secure password manager (as provided by those browsers) is a net
gain for security, allowing users to pick stron passwords.
See also https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
Based on this, the framework should generally consider that
password fields in the backend are meant to be used for *setting*
new values (autocomplete="new-password", i.e. no autocompletion!),
whereas the password field on the login page can indeed be autofilled
with the user's current password (autocomplete="current-password").
In addition to making the above changes, this patch also
lets developer specify their own `autocomplete` attribute on
text input fields.
Be a little less strict when not showing o2m list view warning so if the
o2m is not editable (a modal is open instead of editing inline) we still
show warnings.
Also have warnings over modal overlays so they can be used for modals.
opw-702333
With 003d85b instead of getting the name of the relation
field_relation we get field_relation/id.
But the data about the related fields are not gotten all at once when
opening the export modal. They are gotten by clicking on the arrow of
the related record.
So we need to have these /id information saved in the export list,
otherwise for example the related records can be missing when exporting
from an export list, whilst everything was OK without using the saved
export list.
With the previous change, an export list could contain an id and .id
fields for the same relational field, so a change must also be done in
fields_info method used when getting a saved list.
opw-665994
opw-693535
note: adapted forward-port of 8.0's 29be9ae80 which was lost when
merging web enterprise onto web community.
The Python method `strftime` raises an error when the date is older than
01-01-1900 ("The datetime strftime() methods require year >= 1900"). If
the user mistyped the date (or was expecting 01-01-16 to be converted
into 01-01-2016), this can lead errors since the ORM uses this method
frequently.
opw-702313
An editable list can be drag-and-drop sorted by:
- displaying a sequence field,
- displaying a field with the `handle` widget
At first it was only working if the list was not specifically ordered,
but with 26bf35260 it also worked if the list was ordered on `sequence`
or `sequence ASC`.
This commit changes this so it works:
- if the list is not ordered (same as the original intention),
- if the list is ordered by the sequence field (widget `handle` or sequence)
This allows to have a custom model (on which we can't define _order) to be
ordered on a custom field.
This also remove a far-fetched oddity such as having the view ordered by
sequence but having a custom sequence field before `sequence`.
opw-704612
If the user writes a password larger than 4096 characters at the login
screen, it causes a crash instead of displaying the "Wrong
login/password" message.
The Python library used to hash password (passlib) is by default limited
to 4096 characters. Above this limit, it raises an error (source:
https://pythonhosted.org/passlib/lib/passlib.exc.html).
Allowing a password larger than 4096 is not necessary, we just limit the
field maximum length since such a situation should happen because of an
incorrect copy/paste.
opw-704110
In e0c4ec54ca a change was done to improve the behavior in some
editable list instances, but this introduced a small issue for
list with line creation disabled.
With this change, doing tab or enter at last line should keep the
previous behavior of wrapping around and not creating a new line.
opw-703748
The number of records selected by a FieldCharDomain was only computed
with the base language.
But when selecting the domain with a modal window, or when sending a
mass mailing restricted to a domain, the current user language is used.
With this commit, the number of records is computed with the current
user language.
opw-693836
Christophe Simonis