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
The Work+Sans font of google fonts was hotlinked and available in
reports since saas-14's 3d04e448.
There does not seem to be a reason to do it and:
- hotlinking may add resources usage / processing time,
- server need outside internet access or the font doesn't load,
- it has been reported to cause the header/footer of some pages to
disappear, probably because of a problem with loading the content in
a given delay to render it.
- it was always loaded for report, even if used only once among all the
reports of Odoo
For these reasons, this commit removes the hotlinking of this font.
The ISR report of l10n_ch that used this font will thus fall back on
'Verdana', 'Geneva' then the default sans-serif font which doesn't
seem to be a drawback over 'Work Sans' font.
If at one time we should reintroduce it, it should be contained in the
given report and possibly have the font locally and not externally.
opw-1861368
closes#25683
The call to /web/session/authenticate should return an empty session_info
in case of wrong login/password.
It was producing a traceback (due to self.ensure_one() and search)
Introduced at d1cd293ece and fdb250942Fixes#24071
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.
Have a view with a field as:
<field name="stuck_in_the_middle" attrs="{'readonly': [('with_you', '=', False)]}"/>
Before this commit, the contents of attrs were parsed and merged into the modifiers
and the attrs attribute of the node was deleted
which might cause divergence between reality and tests
After this commit, the mock server does what the server does in this case
closes#25583
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
Application of a fix more specific to the problem of the contact widget
which can not serialize the dictionary because it contains the values of
the context of which browse record. (because contact try to
json.dumps options for multi-edition feature in web_editor)
opw-1859848
https://github.com/odoo/odoo/commit/ab85e9594651fd33ffd2747f4d3c5b360e7c7922
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
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
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
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
len-odoo