New feature:
- New Transparent tag visual (grey border & text, white bg),
- By default, newly created kanban tags are transparent,
- Tag's colorpicker has now a 'Hide in Kanban' checkbox,
to select the transparent color.
Toggling off 'Hide in Kanban' sets the color of the tag as follow:
- Previous color, if 'Hide in Kanban' was toggled on on the
same formview session.
- Color 1 (dark orange), otherwise.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this commit, it was not possible to reexecute functions using the
_.throttle function in the same test (e.g. drag and drop two elements in the
studio tests).
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Consider this: a form view with a one2many list view. In the one2many
list view, there is a many2one field. When opening the manyone in a
modal form view, there is a many2many field. In that situation,
clicking on 'Add a new record' on the many2many field had the
unfortunate effect of interfering with the one2many field in the main
form view, which caused a crash or the modal form view to close
unexpectedly.
The issue is that an event was simply not properly stopped at the proper
location. This is usually not a big deal, but, as described above, it can be
a problem in some cases.
... gives wrong values due to the timezone.
For instance, let's assume that the browser timezone of the user
is UTC+2, and the user types 10/09/2017 10:00:00 in a searchview
with a datetime field in its arch (i.e. which autocompletes on a
datatime field). Before this rev., the suggested value was
10/09/2017 12:00:00, i.e. the timezone offset was added to the
value.
opw 779832
... gives wrong values due to the timezone.
For instance, let's assume that the browser timezone of the user
is UTC+2, and the user types 10/09/2017 10:00:00 in a searchview
with a datetime field in its arch (i.e. which autocompletes on a
datatime field). Before this rev., the suggested value was
10/09/2017 08:00:00, i.e. the timezone offset was substracted from
the value.
We do not take CSS seriously enough, but it has an impact on rendering
speed. The rule removed in this commit slowed down the Qunit JS test
suite by a considerable amount:
With a fresh db with no extra addon installed, community version:
- in chrome, before this commit: 103.2s, with this commit: 54.8s
- in firefox, before this commit: 194.9s, with this commit: 117.7s
This is due to the way rendering is done in web browser. They start
checking css rules from the right, so the *:nth-last-child(2) rule was
checked for every element in the dom, each time it was added/modified.
Note that the rule just above (*:first-child) had no noticeable impact,
but I still think that the universal css selector should still be
avoided in general.
The fun part is that I did not find the place where this rule was
supposed to be applied. I assume that it is just a dead rule. If this
is not the case, we can reintroduce the margin-top with the class mt0,
applied on the specific element.
The JournalDashboardGraph requires nv, which is lazyloaded. Before
this rev., a crash occurred when this widget was instantiated and
destroyed before the loading of the lib was complete (because a
function of the lib was called in destroy()).
For instance, press F5 (to ensure that nv isn't already loaded),
activate some throttling in the network tab, go to Accounting and
as soon as the dashboard shows up, click on another menu.
opw 781628
Before this rev., sorting groups in list views wasn't supported. It
hadn't been implemented in the new views.
This rev. activates the feature, so groups can now be sorted on
their aggregates again. It also implements a basic (first level
only) sorting in mockReadGroup, in the mock server.
opw 781288
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).
For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.
Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.
Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.
Before this revision, only the FormView allowed to reuse the same datapoint.
This was only used when opening a FormViewDialog when opening the form view
of record in a one2many field.
However, this could be useful in other places for other views. In Studio for
example, we need to instantiate a x2m view without the parent view ; we thus
need to be able to reuse the same model for all basic views.
A domain could contain the key `parent` (in an embedded subview), like:
domain="[('display_name', '=', parent.display_name)]")
This is currently not handled by the DomainSelector.
This will probably be handled in a future version but for this stable version,
this case that triggered an error is now catched and an error message is
displayed in the widget.
This was causing a traceback when opening a domain with `parent` in the edition
of a subview with Studio.
The "Event" API is not the same between IE9 till IE11 and all the other
browser (eg: IE Edge, google chrome, firefox, ...).
For example here is a seemingly accepted polyfill to have it working the
'same' on most browsers using CustomEvent:
https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent#Polyfill
This commit just trigger the event with jQuery which attains the same
result but work everywhere.
opw-780056
closes#20759
Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog
There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
This was necessary to force reloading the data, because editing a sub value
in the modal form view could have changed the display_name of the manyone
field. However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
actual rpc was done. However, it may happen that the flag is set to
dirty (for example, when modifying a value inside a many2one), but the
main record has no changed fields.
In this commit, we also remove the on_save handler in the
formviewdialog. This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.
Bug brought by f45edfb
Before this commit, the debug manager crashed when clicking on "set defaults" on a view fetching a fieldDependency.
This was because the "options" key on the field was not set when the field originated from the fieldDependency of a widget.
After this commit, the data_manager ensures that key is present
OPW 780071
closes#20730
An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.
After entering a value in a many2one, if one clicks somewhere else, a popup
is opened to suggest the user to create (or not) a new record with the entered
value.
Before this rev, closing this popup resulted in an unclear situation where the
input was still set with the entered value but the new record hadn't been created.
This commit fixes this by clearing the input value if the record is not created.
See task#36055
Generalization of the field 'intercepts' at the
level of the function addMockEnvironment in
/web/.../testutils.js.
Previously, only createAsyncView had support for
'intercepts'. By moving to addMockEnvironment,
we generalize it, so that even mock environment
others than views could intercept bubbling events.
This is desirable in order to test the app_switcher,
so that we can intercept bubbling events like
'hide_app_switcher' to web_client.
Since addMockEnvironment already makes use of some
special intercepts ('call_service', 'load_views', ...),
We must handle the remaining intercepts afterwards,
hence at the very end of the definition of addMockEnvironment
In the FieldSelector, after clearing the chain and closing the popover,
the very first page was removed from the widget `pages`. This was causing
issue when trying to select a new field again.
This commit ensures that the first page is not sliced.
Before this commit, many2one fields were not (fully) usable in a list view: if
the user wrote some text, then when a dropdown with various choices
opened, pressed the 'down' key (to select a choice), the down keypress
caused a navigation move to the next line, which cancelled the
selection.
In this commit, we make the assumption that if the many2one dropdown is
opened, then navigation moves are not what the user wants.
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
Enhanced version of the traverse function in utils,
so that it also builds the paths to any tree element.
There is a function visit in /enterprise/web_enterprise/static/src/js/app_switcher.js that has almost the same purpose as traverse in /odoo/addons/web/static/src/js/utility.js.
It seems more appropriate to move visit to utility.js.
Also, in order to keep good performance of traverse, it might be better to add an additional 'enhanced' version of traverse instead of making changes on traverse.
Hence the newly added function traversePath.
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
Calendar tests did not go into US for a timezone problem, making it more difficult to correct errors.
To do: pass all the tests js in US (with simplification for the calculations of the times)
Alexandre Kühn