In a form view (account.invoice), have a date field as:
<field name="date" options="{\'datepicker\': {\'warn_future\': true}}"/>
Open a record with the field set to a value
Click Edit, click save
Click create
Before this commit, the value of the field of the new record
took the one of the previous record
On account invoices, it resulted on having the popup "The record has been modified etc...."
And it was not possible to create an invoice from another one
this was because we passed the same reference object for the datepicker
After this commit, there is no popup as the field do not take a value from the framework
OPW 1906085
closesodoo/odoo#28759
Steps:
- open a modal form view from tree view first line and make a change
- open a modal from the second line and make a change
- open the second line back: the change were lost
In a given number of conditions (a many2one inside the form view, there
is a one2many in the form view not inside the tree view, ....) this
happened because:
- when we save the first line, we get onchange data for the second one
- this onchange data can't be applied before second line is loaded, but
it is saved so it can be applied if second line is ever opened
- when the second line is opened the saved change is applied => OK
- when the second line is opened a second time the saved change is
applied again, possibly overwriting posterious change => BAD
With this changeset, when the record with unapplied onchange is loaded
for the first time, the unapplied onchange is applied only once.
Added test without the change failed with:
- only 1 turtle for second partner (result: 0 not 1)
- second partner turtle is Michelangelo (result: "" not "Michelangelo")
opw-1846820
closes#28644
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Some tests were skipped these last months. This is a slippery slope.
The best time to reactivate them is the moment they were skipped, the
next best time to reactivate them is now. So, this is what this commit
does.
Three kinds of tests were skipped:
- 3 password tests
- 2 kanban progress bar tests
- one keyboard navigation test
Password tests
--------------
When the auth_password_policy addon was introduced, two tests in web/
were skipped, because they would fail when the auth_password_policy
addon is installed.
Since then, a commit was done to change the way the password field works
(commit 5bbbd25edf). With this commit,
the password field is no longer an 'include', but a new field widget.
This means that the skipped tests no longer fails.
Kanban progress bar tests:
--------------------------
In saas 11.2, the 'archive all' feature was removed, but it was readded
in saas 11.4. The tests had to be slightly adapted to make sure they
use the proper css selectors.
Keyboard navigation test:
-------------------------
It is now a functional decision not to allow moving from one cell to the
next by using left/right arrow, so this test is no longer valid.
closesodoo/odoo#28685
The file relation_fields_tests.js was a huge 12K lines files for which some editors have a
hard time managing.
We have split it in 4 files to be more managable and removed remove unused data
and import.
closesodoo/odoo#28561
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closesodoo/odoo#28298
Before this commit, when loading the data and calling the prostprocess,
the viewType was not correctly passed which could lead to broken
behaviour. For example, if one was to load a record from a list view
embedded in a form view, the viewtype passed was the list which
prevented to load the data from the form view.
OPW 1891295
closesodoo/odoo#28279
On the user's preference, change the timezone to one that is different
from the browser.
Save the form.
Go back to the user's preferences.
Before this commit, every timezone was displayed inside the span that contain
the warning icon, and leaked everywhere on the form view.
This was because of the joint action effects of commits:
86897ca1674dfabb8f7a
Which provoked the field to be re-rendered in edit mode,
but with an $el on which a span was added. `<option/>` elements
were then added to both `<select>` and `<span>`
This did not happen before v12.0
After this commit, there is no display glitch
OPW 1895088
closesodoo/odoo#28108
Let's assume a one2many editable list containing a many2one field
(e.g. in a sales order, the product_id m2o in order_line o2m), and
the scenario where the user clicks on 'Create and Edit' in the o2m,
and then presses ESCAPE in the opened dialog.
Before this rev., it crashed because the 'navigation_move' (cancel)
event wasn't stop propagated by the form renderer (the one of the
dialog), and thus bubbled up to the list editable renderer, which
asked its basic model to discard a record it didn't know.
Note: same fix as in 8445baa (done in saas-11.3), but with a
simpler test.
Task 1878254
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes#23438closesodoo/odoo#27657
Before this commit, the compute sequence was relying on the fact the ID was used
as a secondary order key to get the right result.
This is necessary when adding items between pages because we don't resequence
the following elements.
However this was not necessary when adding new elements on the last page since
there are no following elements to resesquence in that case.
PR: #27639
Image field widget need the __last_update field alongside them
for caching purposes, though that field should never be present explicitly
in the views
Before this commit, the dependencies of field widgets were not merged into
the model's fields definition, creating a traceback when adding an image field widget
into a x2many list
After this commit, there is no traceback and the image field works properly
closes#27545
stopPropagation of navigation_move event for where direction=cancel,
currently if navigation_move event throws error when user press escape
in dialog where dialog is opened from editable list record
Scenario: Install website_sale -> Open Product form(variant enable) ->
open variant tab -> open Attribute m2o form popup and press Escape on dialog
Result: Error
Expected: It should close dialog and keep editable list view record open,
btw m2o field should also be focused when dialog is closed but that's
another issue, will be fixed in another ongoing task
Related to Issue: #1873919
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
If no value is specified on the datefield, do not set a warnfuture message
Remove code comment that was referring the condition present at b51b0d66c2
but no longer present.
Add tests
Fixes#27551closesodoo/odoo#27593
The datetimepicker option was introduced to be able to customize the
datetime picker widget in date/datetime fields. However, due to the way
the _makeDatePicker function was coded, it did not work in datetime
fields.
Thank to Yajo for the initial fix
closesodoo/odoo#27541
* generic strenght meter widget which can be included in various
places
* password field, taking over the isPassword special cases strewn
throughout the codebase, this should probably become an actual thing
in core /cc @ged-odoo, the meter is opt-in as most uses of
`field[@password=True]` are passwords & secrets for third-party
services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
view for some reason
* direct implementation for signup pages (create user & reset password)
Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).
A recent modification of the float and integer
formatters allowing the rendering to be human readable
causes a bug in the percentage formatter for large values.
The reason is that the latter formatter uses formatFloat (wich can
now produce 'numbers' like 3k) and then parse the result. In the case
of 3k an error is raised since 3k is not recognized as a true number.
This fixes avoid to parse the number in case it has been formatted
to be 'readable'. Note that the parsing was essentially used
to produces better percentages like 10% instead of 10.00%.
This is not necessary in our case since utils.human_number takes care
of the unwanted (not all) decimals for us (the original number is always
rounded by utils.human_number).
Before this fix, in form view, when a datepicker was not visible (because
they were on another page or literally invisible), when the user pressed
TAB and the datepicker was positionned after the current field in the
form, it was capturing the focus during the activate phase of the
navigation_move.
This is not correct for invisible elements.
After this fix, only focusable datepickers get the focus during the
activation phase of the navigation_move.
co-author: aab-odoo (aab@odoo.com)
Before this commit, when we click on the 1st control in
an editable list (usually 'Add an item') then press ESCAPE,
the focus was not on the 1st control.
The intended behaviour is to have the focus on the 1st control,
so that we may navigate left/right between controls solely with
the keyboard.
With this commit, when a cancel keyboard navigation event is
triggered in an editable list, it auto-sets the focus on the
first control.
Co-authored-by: Alexandre Kühn <aku@odoo.com>
This commit fixes a few issues with the previous implementation of the
automatic addition of new lines in x2many inside forms
1. Before this commit, when there is a change of mode in a formview
`edit` -> `readonly` -> `edit`, there may be some cases that
mistakenly and automatically opens a modal.
This case occurs in a form view with a x2many field whose 1st inner
focusable element opens a modal (e.g. "Add an item").
In `edit` mode:
1. Open this modal from the x2many
2. Close the modal
3. Change mode to `readonly`
4. Change mode to `edit`
> the same modal is automatically open.
This is due to the tracking of the last activated field that persists
after a change of mode. Since the last activated field in the 1st
`edit` is the x2many, it is granted the focus at the beginning of the
2nd `edit`, which automatically opens the modal.
This commit fixes the issue by resetting the tracking of the last
activated field when there is a change of mode. As a result, at the
beginning of the 2nd `edit`, the focus should always be on the 1st
field.
2. Before this commit, if the focus was moved out of the form (to a modal
for instance) then back, the form would re-activate the last field, which
is the x2many and would re-add a new line. This behavior is not correct
and now going back from a modal to a form does not add a new line.
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Before this change, when the focus was on the first field on a x2many
field, and the user pressed TAB, the line would be discarded and the
focus moved to the next field (at the level of the x2many) in the form.
This was an issue because if the first field was required, the focus
could not be moved out of the field with TAB so the user had to discard
the line manually (with ESC) before moving to the next field
This change works with 2 changes:
1. detecting if a line is dirty (has been modified by the user) and at
the end of the line, decide to either
- discard the line and move the next field, if the line is not dirty
- commit the line and add a new line, if the line is dirty
2. allow users to use TAB through required field inside x2many so they
can easilly go to the end of the line.
Task id : 1872248
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
This rev. is similar to db9b91ff, but treats the x2many case.
Calls to the 'commitChange' function of renderers must not be done
inside a mutex, mainly since 241704536, as they could end up in a
deadlock. For x2manys, it was actually the case in practice in
Inventory > Operations > Inventory Adjustments > Create > select
'One product only' > select a product > try to edit the real
quantity in the editable list > focusout > deadlock.
The reason why the deadlock occurred in this view and not in, e.g.
sale.order, is due to the presence of the field_float_scannable
widget. Indeed, the barcode engine intercepts input events and
manually re-triggers them. As a consequence, the 'change' event is
not triggered on the field, and it does not notify the environment
of its new value by itself, until the field x2many asks it to
commit its value. Note that this might be an issue as well, as
onchanges are thus not triggered.
Task 1878254
Christophe Simonis