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
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 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
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
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
When a user fills partially a date or datetime field, the system will
somehow autocomplete the value entered. For example, if the user enters
"11//11" then clicks on the Tab key, it will be completed as
"11/11/0000".
However, the year 0000 is not recognized in Python, and this causes a
crash upon saving.
opw-695035
Rev. 3f7d350fe21d9e2afb35a9ce3e2652940e3f259d1 introduced
auto-cancellation of the edit mode when the user clicks
outside the edited line.
The unfortunate downside was the auto-cancellation of the
edit mode also when the user presses ENTER while the
line is not valid.
This is especially annoying when using barcode scanners to
fill in values, as scanners usually send an ENTER keystroke
at the end of the input sequence.
When a many2one field is focused this event will often occur
before the autocompletion popup has a chance to open. At that
point the line is considered invalid, and the edition mode
is cancelled! If no field is considered dirty yet on the line
this simply drops the whole line, otherwise it will open a
navigation confirmation popup. Both results equally prevent
the use of barcode scanners.
This patch makes sure the edit mode is only cancelled when the
user indeed clicked outside the line, and not for other cases
where save() is requested, such as an ENTER keystroke.
If the graph view was left while a nvtooltip was shown (thanks to
keyboard shortcuts or during loading time), the nvtooltip remained
and was only destroyed when leaving the action.
Now they are automatically removed with the view as they are now
placed inside of them instead of inside the body element.
Up to this commit, the JS module system only notified failed modules as
an 'information' instead of an 'error'. This was annoying, since the
runbot takes the result into account, and might be green even though a
module failed to load.
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Forward-port of 5d17749ff4 which has been
forgotten during previous forward-port.
When clicking on the trash to remove a line (e.g. a sale order line
in a quotation form view) while editing another line, it produces a
traceback (in most cases), or behaves randomly (less frequently)
like removing both lines, or one of them, or maybe none of them.
Anyway, this feature doesn't work at all, so this commit simply disables
it when we are in edition mode.
In a perfect world, we would fix the feature instead of disabling it,
but the code of the list editable is so instable that it would most
certainly break something else.
Closes#13778
Underscore method _.each expects an array like object when a
"length" property is present.
This was an issue with a record having a numeric "length" field set
to a non-negative value.
opw-691070
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Nicolas Martinelli