The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
Let's assume a quick create form view with an onchange. Before
this rev., if the user set a value for the char field with
onchange, then clicked on 'Add', the record was created before
the onchange was applied, and thus with incorrect/incomplete data.
The reason is that, when clicking on 'Add', the user triggers a
'change' event on the char field, which notifies the model of its
new value. Then, as 'Add' is clicked, the quick create widgets asks
all widgets to commit their potential (uncommitted yet) changes.
But there is nothing left to commit as the changes have just been
notified. The quick create only waits for this to make the create
RPC, and thus totally ignores the changes that were committed at
the first place.
Task 1878254.
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.
A new exception has been added to detect inconsistent reports. However, many are not structured as expected. Thus, the change consists mainly of checking only when the print has to be separated in part to attach it to the respective documents.
We now take the page tag instead of the article, because the article tag is in the layout, so to separate the file, the t-call had to be inside the t-foreach (for the separation) and so possibly read the assets several times. Since all templates have the first tag (in the t-foreach) tag page, the choice is more sensible.
The javascripts files used in readonly were taken out of the editing assets.
A turn was made but not activated, it works locally, but on the runbot, an error is triggered when generating assets after choosing the settings.
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.
This commit fixes a bad behavior of the pivot view. By the
past, if there were no data to present in the pivot view, no
information on the pivot view configuration was returned by
the get function. This does not cause problems to the pivot
renderer (by design) but causes problems elsewhere, for
instance in a dashboard view that contains a pivot view.
Indeed, at each update, the dashboard view reinstantiates its
subviews, so that information can be lost if a subview is of
pivot type.
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.
The search view in mobile mode has been redesigned and looks a bit different
from the search view in desktop mode. This commit adapts the time range menu
appearance in mobile mode.
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.
The buttons 'Flip Axis', 'Expand All', and 'Download xls' are
now deactivated when no data are displayed in the pivot view
(those buttons are useless in that situation).
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
When starting the clickEverywhere test with enterprise modules
installed, it happens that Odoo web client is not yet fully loaded.
In this situation, the test does not find any app to test.
With this commit, an attribute is added to odoo to check if the web
client is fully loaded.
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
* web, website
- Introduce gray color palettes (needed for themes migration)
- Synchronize BS4 color maps with individual variables (see comments
about this in the code).
- Review alpha/primary, beta/secondary matching:
Before this commit, we decided that the common way to define a color
palette was defining primary, secondary, gamma, delta and epsilon.
alpha and beta were then forced to primary and secondary without other
possibility.
The new system makes more sense:
1) define alpha, beta, gamma, delta and epsilon
2) primary and secondary will automatically be set to your alpha and
beta (allowing to style the default UI with BS4-independant
variables)
3) if you are not happy with (2), you can define primary / secondary
in your color palette so that they are not automatically set to
alpha / beta
This commit also changes what classes the editor uses. Background colors
and text colors will now use alpha/beta/gamma/delta/epsilon (not primary
and secondary anymore). For buttons, all the possibilities are suggested
but color duplicates are hidden (so if your primary and alpha are equal,
only one button color is suggested).
The goal of this commit is to fix the various views and reports of sales and invoices.
======
Portal
======
Fix breadcrumbs
Fix BS4 issues, alignment of various elements
Better auto resize of the invoice iframe
Fix invoice list for draft invoices
Fix previous/next document pagers
Remove unnecessary monetary widgets (not needed when using t-field if the field is Monetary)
Standardize invoice and sale routes:
- especially when related to displaying: html, pdf (print and download), text
- by using the get_portal_url() also for invoices
Add the total on the left column of sales order
================
Section and note
================
Improve general style:
- notes in italics
- sections: less padding, darker background, no borders
=========
Demo Data
=========
Fix sales order demo data to appear for the admin (instead of system)
PR: #25997
task-1869469
This commit adds a new js test in web that enters each app and click on
each view switcher, each menu and each search filter.
This test is tagged '-standard' and 'click_all' as it could last a long
time, that way it's not executed by default.
It could also be started from the browser console with
'clickEverywhere();'.
momentjs `isSame` method considers undefined values but not false
our method _isSameValue does consider false
Correct the error when running web tests
Deprecation warning: value provided is not in a recognized ISO format
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
doc:
* fix incorrect doc comments (documenting params which don't exist)
* correctly quote non-refs
* fix role label syntax (backticks must be escaped)
* add newline to fix warning
JS doc parser:
* fix handling of already-resolved objects
* fix handling of non-string properties (e.g. foo[0] at module toplevel)
* don't blow up if subject of .include call can't be resolved (just ignore)
Others:
* add translator support for ``problematic`` node (apparently used for
some refs by recent Sphinx)
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
Christophe Simonis