Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.
Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.
closesodoo/odoo#32408
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The widget has been moved in rev. odoo/odoo@15f3bbe but was not very generic.
In particular, there was a traceback when clicking on the button if the field
had no value (the button was displayed for readonly fields in create mode).
The button is now only appended in readonly mode (a `button` inside an `input`
or a `textarea` is not very DOM friendly) if the field has a value.
Task 1941996
closesodoo/odoo#31635
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.
tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.
opw-1922437
closesodoo/odoo#30276
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
The current implementation of the state_selection widget always makes it
editable even if the field is readonly.
We improved this behavior by removing the handle of click on the widget
when the field is readonly, but keeping it even if the view is not in
edit mode, because it used for example in project to change state even
when view is not editable.
closesodoo/odoo#29218
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
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 option `showSearchInput`, which is used on the model field selector to display a search
input that filters the displayed fields, is not set by default.
This includes the model field selector instantiated in the `domain` field widget.
closesodoo/odoo#29986
Have a form record with a progress bar
Modify the max_value of the progress, as well as the current_value bar through an onchange
Before this commit, the new max_value was not taken into account
After this commit, it is.
closesodoo/odoo#29056
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
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
Before this commit, when focusing on a date[time] field, the value was not selected
In v11.0, it was
This is due mostly because of the migration to BootStrap 4
After this commit, the value inside the input is selected
OPW 1911333
closesodoo/odoo#28989
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).
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)
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
Hardening of commit:995610c065bf0242cb5023cfad2940234395739e
The JournalDashboardGraph requires nv, which is lazyloaded.
However it requires nvd3.js which is loaded after nv.d3.js.
A function called in destroy is defined by nv.d3.js,
which can make the crashhappen with the right (wrong) timing.
opw 1873749
This allow the browser/device to handle the experience of handling number in a more native way.
FieldInteger and FieldFloat now inherits from NumericField because we want
to format it or not dependent of the view (readonly or edit) and the
NumericField will manage it.
We do that because input type number can't take a value with comma on Chrome
(FireFox is more permissive but not perfect because comma is the separator
for decimal in this case).
Task #1880376
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
Aaron Bohy