Browsers add a 1px padding to inputs but they don't do it for the
select elements, which makes them unaligned.
Tested under Chrome 68, Firefox 61 and Safari 11 on MacOS 10.13.6.
When cliking on a calendar cell user is redirected to a form view to create
a new record. However if the calendar action gives a specific form view ID
it is not taken into account by calendar.
Calendar code still handles views as not being a structure holding viewID and
type but just an ordered list of items with (view ID, type). This commit fixes
that code. One calendar JS test is updated to correctly match the current
structure.
This commit is linked to task ID 1876795 and PR #26571.
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
Up until now, the execution of a report action could not be followed by
any action which prevented, for example, to automaticcaly close a modal
after printing a report from it. This has become an issue when working
on customer's invoices using the new modal introduced in 4cb9194275
This commit allows to close a modal after the download of a report.
Removing the code that allows to generate multiple reports with a single
action introduced in 410d6a703b as it was
only used for l10n_ch and that this was abandoned in
5169b50efe.
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
Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.
This is because in the refactoring adding modules (e8a00bc50d) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.
But there was still an usage of the removed implementation.
opw-1880766
closes#26816
Before this commit, the `dom.autoresize` function may apply the
padding and border width twice when computing the height of the
textarea. This issue occurs when the fixed textarea had the same
CSS style as the textarea.
This commit fixes the issue by enforcing zero padding and border
width in the fixed textarea.
Task-ID 1882736
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).
David Monjoie