Before this commit, the style of the value and text in some stat buttons were
broken.
The design of the stat button is to have a single value and a single text which
are stacked as follow:
[CSS] [Visually] [Example]
.o_stat_info +---------+ +------------+
.o_stat_value | | | |
.o_stat_text | value | | 10 |
| text | | Forecasted |
| | | |
+---------+ +------------+
However, some stat buttons use multiple values or texts. For example:
[CSS] [Visually] [Example]
.o_stat_info +-------------+ +------------+
.o_stat_value | | | |
.o_stat_info | value text | | 3 Hour(s) |
.o_stat_value | text | | Lost |
.o_stat_text | | | |
.o_stat_text +-------------+ +------------+
[CSS] [Visually] [Example]
.o_stat_info +---------------+ +---------------+
.o_stat_text | | | |
.o_stat_text | text value | | Min: 10.00 |
.o_stat_info | text value | | Max: 20.00 |
.o_stat_value | | | |
.o_stat_value +---------------+ +---------------+
The latter is works fine with block, which guarantees vertical alignment.
However, the former case has some alignment issues like this:
[Visually]
+------------+
| |
| 3 |
| Hour(s) |
| Lost |
| |
+------------+
This is due to the use of `display:block` for any `.o_stat_text` and `.o_stat_text`.
This commit fixes this issue, without affecting the other cases.
Task-ID 1841523
Before this commit, there was a traceback when clicking on a button
that generates a button call action with type `'button'`.
This is due to the handler of such an action that assumes only a small
set of button actions. Each of those cases correctly sets the local
variable `def` to a deferred, so that the post-processing is correct
(i.e. it handles this variable as a deferred). However, this is wrong
with a different button call action, so that this variable is `undefined`
instead of a deferred.
This commit fixes the issue by ensuring that the variable `def` is always
a deferred. As a result, the post-processing can make the correct assumption
that this variable is a deferred.
Steps to reproduce:
- Install Google Drive Integration app
- Go to General Settings
- In the category "Google Drive", click on "Get Authorization Code"
(displayed as "Get Author...")
Task-ID 1861630
The value of the statinfo widget is rendered by the qweb after a t-esc.
Say if the python rounding returned 14.0000000001
(supposed to be a two digits precision number through the magic of floats)
then the statinfo widget would print it as-is.
We now format the value at assignation.
opw 1865426
On a database where many modules are installed (e.g. runbot all), with
the option "manage available packaging options per products", doing a groupby
"product" on the "package type" list view triggers a js error.
It comes from the fact that the fixed_group variable contains a "length"
attribute; the _().each function uses this to determine (erroneously)
that the object is an array.
It thus uses fixed_group[0] to get an undefined, and then tries to access
a method of undefined.
We replace the each by a simple js loop.
opw 1863576
In a search view, write text in the input, then hit enter to select
the facet.
Before this commit, the search view was detached and then reattached
when the control panel was refreshed. This led to loosing the focus
momentarily and erasing any supplementary input one might have typed
*during* the rpc call.
After this commit, if the search view is the same as before, we don't
detach it in the first place. Thus, the input is conserved in this
situation.
OPW 1861941
OPW 185614t
closes#25546
In a one2many, if the user clicked the trash button while editing another line,
the row was not unselected.
Thus the modal was not triggered, which entailed that the currently edited line
was always saved.
In particular, it allowed to give empty values to required fields.
opw 1834346
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
Steps to reproduce the bug:
- Go on a SO and click on "Send by email"
- Remove the attachment and click on "Add an attachment"
- Choose an attachment A and remove it by clicking on the cross
- Click on "Add an attachment" and choose the attachment A
Bug:
The attachment didn't appear in the modal.
opw:1862482
Before this commit, it was not possible to add an amount to a new
bank statement. The input (.o_form_field_monetary) appeared as disabled.
This bug was due to this commit: @a1224f5ca
This rule should be only applied to .o_form_field_radio.
Closes#18887
Task ID: 35832
*: hr_gamification, point_of_sale, web
Before this commit, no content helper in some form view fields were broken,
due to the style of the classname `.o_view_nocontent` that uses an absolute
position.
This is due to some templates that wrongly use this style for displaying a
help message, although this is only valid for views with no record.
This commit solves the issue by using another classname for those fields
with the nocontent helper, namely `.o_field_nocontent`.
Before this commit, the point of sale displayed a loading message
every 5 secondes if the barcode scanner was configured.
This issue is due to the following commit: @1aacc96
After this commit,some calls may block the interface when they did
not do it before.
It concerns all rpc done with ajax.rpc and all done with a new
session.
We have now to explicitly set shadow property.
opw-1860493
Let's assume a one2many A inside a form view, such that the one2many
views (list, not editable, and form) are defined inline, and there is an
onchange on A. There is another inline one2many B editable list
displayed in the inner form view (and B isn't in the list). There are
two records on the one2many A, both of them having one record in their
one2many B. Edit the first record of A, and edit it's subrecord in B.
Click on save. This triggers an onchange on A and the onchange returns a
command 5 (DELETE_ALL), and two commands 1 (UPDATE). Now edit the second
record of A, and simply close the dialog (e.g. 'Discard'). Save the main
record: the record in one2many B of the second record of A has been duplicated.
This occured because the code in BasicModel messed up information coming
from the onchange (UPDATE command) and from the read (performed when
opening the second record), thus producing a CREATE command instead of
an UPDATE one.
This rev. ensures to properly mix the read data with the onchange
result, by transfering the changes over the list datapoint created after
the read.
opw-1836785
closes#25330
Let's assume a one2many list with two fields A and B, and an
onchange on A that sets B. Before this rev., on new records, the
onchange was only triggered if the one2many list was defined
inline.
Rev. 13c885195 was an attempt to fix the onchange issue in x2manys
with non inline views, but it only worked on existing records. This
rev. fixes the problem for both cases (existing and new records),
and thus reverts the fix of 13c885195.
The idea of this fix is to make both cases behave similarly, w.r.t.
fields and viewFields stuff in the fieldsView. In the inline case
(like in the main view case), fields and viewFields are the same.
In the non inline case, viewFields contained more information than
fields. As fields is used everywhere in BasicModel (and viewFields
is basically ignored), the fix is to set fields to viewFields.
Have an action that opens a dialog, with a specific callback
to execute when the dialog closes
In the dialog, have a button linked to an action that opens
another dialog in target = new
Close this 2nd dialog
Before this commit, the callback was not executed
After this commit the callback is executed
OPW 1853136
closes#25180
When clicking on an action button, the following steps are performed:
1. Buttons are disabled
2. The button call is performed
3. At the end of the call, the buttons are enabled
4. Extra RPC are performed (`read`, `name_get`)
5. When the RPC calls are finished, the form is reloaded
In the case of a validation of a SO, it means that the 'Confirm' button
is enabled at step 3, but hidden at step 5. On a slow network (or an
overloaded server), it means that the user has enough time (step 4) to
click again on the 'Confirm' button and trigger the action more than
once.
The root cause is that we don't retrieve the promise of the `reload`
mechanism (defined in `_callButtonAction`) when executing `on_close`
(triggered after the button call). We return a promise which is resolved
and enable the buttons too early.
We make sure to retrieve the promise of the `reload` and return it, so
that the promise of `saveAndExecuteAction` (defined in
`_onButtonClicked`) is correctly linked to it. This way,
`_enableButtons` is called when the reload is performed.
Co-authored-by: Aaron Bohy <aab@odoo.com>
(well, actually he did most of it)
opw-1859027
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
Avoid to crash the client web with setValue(false).
false.match, false.split, false.length... will not works.
Before this commit, _render call the setValue after comparing '' !== false
Before this commit, load_action and load_views were never resolved
in case of internet connection loss.
It's because the call is triggered by web.rpc direcly who uses
ajax.rpc without any response check.
Now the rpc response is checked in web.ajax.
Thereby all responses are handled whether they come from session.rpc
or rpc.query.
Plus, it was not the responsibility of the session to check the
rpc responses.
Steps to reproduce the issue:
(1) load_action:
- Go to the app switcher for the first time
- Force disconnected from the network
-> No notification appears and the user aren't notify
(2) load_views (mobile only):
- Go to Sales -> Quotation
(In this case, the first call is 'load_views' because we need to force
to load some views like kanban view)
- Force disconnected from the network
-> No notification appears and the user aren't notify
Note: It's now important to notify the user about connection loss
because a recent improvement in mobile app replaces the 'retry screen'
and lets the webclient handle connection issues by itself.
The single odoo mobile app is supposed to work with all databases
from 10.0.
The lower-level widget itself supports passing options to the underlying
datepicker library. However this is not exposed to higher-level view
declaration. With this patch, one can declare a field in a view such as:
```xml
<field name="datefield" options='{"daysOfWeekDisabled": [0, 6]}'/>
```
That option would land in the widget and disable those weekdays.
Documentation has been updated accordingly.
Closes#25044.
Before this commit some rpc was blocked and we didn't see
lost connection notifications.
Steps to reproduce:
1) Go to any form view
2) Force disconnected from the network
-> The "Connection lost" notification appears
3) Get connection back
-> The "Connection restored" notification appears
3) Close the connection again
-> No notification appears and the user aren't notify
that the internet connection is lost.
Related commit: @47cf31b53
Note: It's now important to notify the user about connection loss
because a recent improvement in mobile app replaces the 'retry screen'
and let the webclient handle connection issues by itself.
The single odoo mobile app is supposed to work with all databases
from 10.0.
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes#24988
To compute the week number, the fullcalendar.js library uses the locale.
It depends on the day on which the week starts (usually Sunday in the Americas,
Monday in Europe), as well as which week is considered the first of the year.
In commit:
https://github.com/odoo/odoo/commit/717b472ef9ad6d2998cbefb4aafe2d1199e6235d
the starting day was explicitly added, however it was computed as isoWeekday.
The ISO first day of the week is always on Monday.
It resulted that if the locale used Sunday as first day of the week, the
calendar would consider it to be of the previous week, and thus displayed
(weeknumber - 1).
The fix does the same thing as was done in v10, taking the locale into account:
https://github.com/odoo/odoo/commit/df124080b624a8bdb86fec352fe690725ed36bac
opw 1853745
In some cases, the calendar view sends a trivial domain, such as
["partner_id", "not in", []]
This is clearly not really useful, and it could hurt performances in
some cases (for example, if the partner_id field is a related on a large
table, and non stored).
This is clearly not a complete fix, but it is easy, safe and does not
hurt.
Model A has a o2m to model B
Model B has a m2o parent_id on B
In A's form, add a B item,
then in the m2o, create record
Save and New
Click on the m2o
Before this commit, the python crashed on name_search.
This was because we sent the virtual ids to it
After this commit, there is no crash
OPW 1850212
closes#24948
Have a decorated (conditional on field) editable list, with a default_order.
Have more records than the pager allows.
Add an item, and hit escape to cancel addition.
Before this commit, the cancellation crashed because the first record on the other page
was trying to evaluate the decoration for its row, which is wrong in the first place.
This was because creating a record increases the limit of the list, to be able to see the record
being created.
At cancellation though, that limit was never decreased.
After this commit, the whole flow happens without problem.
OPW 1844495
closes#24682
Let's assume the following scenario: in a kanban view with a
domain, remove that domain and quickly click on a record to open it
in form view. On a slow network, it may happen that the reload of
the kanban view (triggered by the domain change) returns after the
load of the form view.
Before this rev., when this happened, the form view was correctly
displayed but the control panel contained the buttons, searchview,
pager... of the kanban view.
Note that this fix is quite ugly, but it won't be necessary anymore
as soon as the control panel won't be shared between actions and
controllers, i.e. as soon as each controller will have its own
control panel.
Let's assume the following scenario in a Kanban view with a default
filter. The user removes the filter, and quickly adds a new one.
On a slow network, it may happen that the second reload request
returns before the first one. On odoo.com, this is easy to
reproduce on the tasks Kanban view.
Before this rev., when this occured, the result of the first
request was displayed, whereas it should have been ignored as
another request was done later on.
Christophe Simonis