This rev. adds a new function to the mutex concurrency helper:
'getUnlockedef'. This function returns a deferred resolved as soon
as the mutex has no more task to execute (or directly if it is
currently idle).
Such a function was needed for an upcoming fix.
Related to task 1878254.
Before this rev., if the user clicked several times on 'Add' (or
pressed several times 'Enter'), on a KanbanQuickCreate record,
multiple records were created.
This rev. makes sure that this doesn't happen anymore by locking
the widget when it is creating a record ('create' RPC that might
be preceeded by an 'onchange' RPC).
Several test cases are added, to mock the different scenarios that
could occur, as they are all slightly different (depending on if
there is an onchange or not and if the user clicks on Add or press
Enter).
There is still a scenario that needs to be handled, which is the
one with an onchange and where the user clicks on 'Add'. This one
is more tricky and will be handled by a future commit.
Task 1878254.
This rev. removes a deadlock situation that could *theoretically*
occur, but that was actually hard to reach in practice.
Before saving a record (e.g. in a form view), all field widgets
are asked to commit their value (in case they wouldn't have
notified the model yet, e.g. because the user just changed them).
For instance, let's assume that the user fills an input field, and
then triggers the save. In practice, by triggering the save, it
will force the widget to notify the model of its new value (because
it looses the focus). This is also the case using keyboard
navigation, as it actually simulates clicks. So when the widget is
asked to commit its value right after, it has nothing more to
commit.
This is fortunate, because if it actually had something to commit,
we would end up in a deadlock ('commitChanges' is executed in a
mutex, and if the widget triggers a new value, '_applyChange' is
called, and is executed in that mutex as well). In fact, executing
'commitChanges' in a mutex is useless, as '_applyChange', which is
called when a widget has something to commit, is already executed
in the mutex.
So this rev. removes the use of the mutex in 'commitChanges'.
Doing so broke several Many2One tests, because they wrongly relied
on the presence of the mutex for scenarios where the user quick
creates a relational record, and then directly saves (before the
relational record is actually created). We thus handled that
usecase properly to make the tests pass.
Task 1878254.
This commit changes two things in the time range menu
appearance:
- the order of range options
- the spacing between them (now two different groups
are separated by an empty lines)
Some tests had to be changed accordingly.
The _mergeData function used in pivot view comparison mode
was not designed to accept the absence of the __count key or
null values for measures in the objects returned by a 'read_group'.
The absence of the __count key would result in a traceback and null
values for measures into wrong calculations (infinities).
One could ask why null values did not cause problem before.
The simple reason is that the formatters used to format cell values
render a 'null' value like they render a zero.
This fix makes explicit that null values have to be considered
as zeros and avoid in that way Infinity values when computing
variations.
Exporting data of a pivot view in comparison mode ends in a
crash. The root cause is that _t was replaced by _lt
so that some strings were replaced by objects with a toString method.
This does not cause problems when rendering a pivot view since
both QWeb or JQuery call that method. The function _exportData does not.
This commit fixes that situation and adds a test of _exportData.
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes#26676
Revision on https://github.com/odoo/odoo/commit/017e71322b6b7f0c232f0d66ba659a5972fc3534
Commit above correctly fixes an issue with 'Edit View: X' menu item
in the debug manager, in which the name of the view was missing.
To do so, it lets the controller be aware of the name of the view,
so that it can be used in the template of the debug menu.
However, we think there is a much better solution to fixing this
issue: since the debug manager has knowledge of the view action,
we can extend this object with the name of the view.
This is exactly what this commit does: extend the action view object
so that it knows the name of the view. That way, the template is much
more readable, as `view.displayName` is more meaningful than
`controller.viewName`.
Task-ID 1878254
Revision on https://github.com/odoo/odoo/commit/f7fbe8adffb1ee585c8171f6c86d38145c11848d
The commit above wrongly assumes that the object 'view' is an instance
of the view class. As a result, the property `display_name` was undefined.
This commit fixes the issue by letting the controller remember the name
of the view in a similar was as the type of the view. That way, the name
of the view can simply be retrieved from the instance of the controller
class.
Task-ID 1878254
Be in a grouped kanban view with progressbar with limit 10:
- records 1 to 10 are loaded on a column
- do "Load more..." on a column => records 11 up to 20 are loaded
- do "Load more..." 2nd time => records 11 up to 20 are loaded
- do "Load more..." 3rd time => records 11 up to 20 are loaded
- ...
While in reality it should be:
- do "Load more..." 2nd time => records 21 up to 30 are loaded
- do "Load more..." 3rd time => records 31 up to 40 are loaded
- ...
This was caused by the progressbar reloading the column's group. This
set the loadMoreOffset to 0 thus forgetting the current state.
Without the change, added tests failed with:
records of column are loaded => actual: "1,2,2", expected: "1,2,3"
opw-1878359
closes#26628
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
The pivot view didn't take into account the widget set on the fields.
In particular this was a problem for float fields that store time values.
They are now displayed with float_time if declared as such in the view.
opw 1876445
Revision on https://github.com/odoo/odoo/commit/3210f108272be89f1a7b01f4e1816b7f04ae0a3b
Before this commit, when doing an action that opens a dialog
(with `target: 'new'`), then triggering 'history_back', the
`on_close` handler of the action was never called.
This was not the correct behaviour, because the dialog closes
without the `silent` option set. Indeed, when this option is
not set, it should always call the `on_close` handler.
The bug comes from closing the dialog without any options, and
this case was not handled correctly in the commit above. This
commit fixes the problem by ensuring that the `on_close` handler
is called even when closing the dialog without any option.
Before this commit, it was not possible to compare data if the time
range selected was quarter or last quarter.
String and integer was concatenated and the returned domain to evaluate
was wrong:
-3 3 - (context_today().month - 1) % 3
instead of:
-3 + 3 - (context_today().month - 1) % 3
Offset period param is always an integer but it's not the case of
boundary params. For 'quarter' and 'last quarter', it's an
expression to evaluate.
Anyway, this part of code will be refactored in a while but it's
important to make the test to avoid this king of issue.
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
289adeb63f introduced a bug where we tried to trigger an event on an element that didn't exist. Indeed there is no input if it's not in edit mode.
This commit fixes it.
PR: none
Task: none
When there is no handle field, there was an unnecessary margin-left. When there was a handle field, the margin-left wasn't the correct way to align it.
PR: #26566
Task: 1869469
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
Before this commit, when we applied two or more groupbys in line
graph, the groups displayed on the X axis where shifted to the left,
and the first one wasn't displayed at all.
related task: #1848289Closes: #25037
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
Rev. 241704536d highlighted a bug in the Kanban RecordQuickCreate
widget, when a form view is used inside the widget.
Let's assume a quick create form view with a char field. The user
fill in this field and press 'ENTER' (without focusing out). The
record is about to be created. But first, we have to ask all fields
to commit their value (through 'commitChanges'), in case they
wouldn't have yet. The char field thus notifies its parents of its
new value at that moment. The form controller handles this request
in its '_applyChanges' function, but this is done in its mutex (to
prevent overlapping onchange RPCs). Unfortunately, this leads to a
deadlock as the quick create form controller already executed the
'commitChanges' request in this mutex.
Actually, there is no need for the quick create form controller to
execute the 'commitChanges' request in the mutex, as it is already
properly mutexified upstream. This rev. thus remove the use of the
mutex at that spot.
Note that before rev. 241704536d, the bug didn't occur because the
'commitChanges' function of InputField didn't return a deferred,
and thus the mutex was unlocked directly.
To be complete, let us mention that there are still some
concurrency issues with the quick create widget (like multiple
records creation on double clicks or double 'ENTER' keypress).
Those issues will be tackled in a future commit.
Task 1878977
Before this fix, the list grouped did not render correctly when
the list was not selectable and there was 1 or 2 fields (the sum in the
footer was not aligned on the correct column)
Also fixed the fact that the group pager was not displayed if the list
had only 1 field and it was grouped
-Some tests where moved without addapting the path to them:
path is now update and tests fixed.
-A picture was removed in commit 4dce6cc98b but
still referenced in template website_twitter_snippet.
-A test was missing a data leading to the wrong path to image beeing loaded
Since we correctly compute the height of the field, we don't want to let the user resize it vertically.
This was already working on Firefox because it doesn't require the field to be in the DOM to read the resize attribute, but Chrome does require the field to already be in DOM.
Task: 1869469
PR: #26518
Before this commit, a textarea inside a one2many would only have the correct size after focus or on change.
When we select a line, we want all of the textarea of the line to have the correct size even if they are not directly focused.
Task: 1869469
PR: #26430
Before this commit, a textarea would not resize when its value changed if the event was different than "input" or "focus".
This commit fixes it by also listening to the "change" event, and by triggering it at appropriate times.
PR: #26430
Task: 1869469
The box-sizing property was not correctly taken into account.
- content-box is the standard behavior: border and padding are added after the height
- border-box needs attention: border and padding must be included into the computed height
Task: 1869469
PR: #26430
In a one2many, pressing ENTER or TAB from a required input (of type text or char) that is on the last editable column of its line would fail to navigate to next line.
The issue was that the validation of the required field would happen before the change to its value was actually applied.
This commit fixes it.
PR: #26430
Task: 1869469
This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
Aaron Bohy