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.
Revision on 8ac98fc78a
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
Before this commit, some records in a list did not show the name of their
many2one fields.
This case occurs when the records in the list are created from a default_get,
and the records do not fit in a single page. In that case, the records in the
first page correctly display the names of their many2one fields, but not the
records in the other pages.
Fixes#24547
Before this commit, when a list contains records with many2one fields that
contain the same values, duplicate ids were passed to the server on rpc
`name_get`.
For instance, if 40 records in a list refer to a Unit of Measure with id "1"
whose displayed_name is "unit(s)", the server receives a long list of ids with
simply the value "1". Also, the server responds with a list of displayed_name,
in this case a list of 40 strings "unit(s)".
With this commit, we always pass unique ids to the server on rpc `name_get`.
When posting an svg image, Odoo tries to resize it for thumbnailing
(like any image).
However this is of no interest since this is a vectorial file format, and
furthermore it distastefully makes the image library Pillow crash, since it only
supports raster formats.
The result would be a broken thumbnail instead of the image itself.
By not setting the thumbnail size if the mimetype contains svg,
we ignore the thumbnailing altogether.
Note that this only applies to the admin user, as otherwise the file is
treated as binary and thus no thumbnailing occurs anyway.
opw 1841153
Commit bcd4c90 was intendend to make get_file handle uncaught/unserialized exceptions
in the context of a http request
The drawback is that when get_file received a serialized exception (route: /report/download)
the JS modal was empty in that case
This commit handles both the cases
OPW 1848606
closes#24794
In case we define a field like,
<field name="my_domain" widget="char_domain" context="{'active_test': False}"/>
when selecting records the dialog should display all records (as asked by the
context), but it's not the case.
This commit ensure the field context is passed to the selection dialog.
opw-1831902
When sorting records according to a many2one field in a list view
embedded in a form view, the js would sort according to their ids,
in a seemingly arbitrary order.
Thus sorting records according to a field with values in ("a", "b", "c")
could be sorted as "a", "a", "c", "b" instead of "a", "a", "b", "c".
We make the comparison on the name of the field instead.
opw 1838860
Recently, rev. c0809dd41 removed a protection in the reload of
Kanban views with progressbars. This protection ensured that the
manual reload of the progressbars was only done when one of the
records of the Kanban view was updated (and not when a column, or
the whole view was).
However, removing it highlighted a bug linked to the manual reload
of progressbars, which messed up the list of ids in the
environment. As a consequence, for instance, if the user archived
the records of a column, and then opendc a record in form view,
it couldn't use the pager anymore.
Besides fixing this bug, this rev. re-introduces the protection,
and refines it to prevent 2 useless RPCs when the whole Kanban
view was reloaded.
opw~1841276
opw~1841342
Before this commit, we had the following issue with binary widget in a form:
Suppose we have a binary field with filename attribute set. When uploading a
new file 'temp.txt' with content 'Cg==', the displayed value is 'Cg=='. When
the changes are saved, the displayed value becomes 'temp.txt'.
It should always display 'temp.txt', which is what is fixed by this commit.
In addition to fixing this issue, we describe what is the expected displayed
value of a binary field. This is based on whether the attribute filename is
provided, and whether the record is in edit or read-only mode.
Fixes#21630Closes#24275
Co-authored-by: Nick Booker <nick.booker@opusvl.com>
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
When we edit a list view and change page before the change has been
savec, the saving and page changing will be done concurrently thus
possibly causing an error if the page is changed before the saved is
finished: the save will try to modify the page that is no more
displayed.
In this change, the list view editable wait for the saving to be
finished before reloading its content.
note: for 9.0 up to saas-15
opw-1839149
closes#24471
Géry Debongnie