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
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
Have a One2Many
The views of that o2m define two inline views: the list and the form
in the list view, put a field that isn't in the form and used in a domain
Try to add an item to the list
The form pops up
Fill in the data and save & close
Before this commit:
It crashed when evaluating the domain on a field using the field that is not in the form
After this commit:
Subviews share their fields in a special object on the parent record
In our case, the form view checks in that shared resource if the fields it is supposed to initialize
are there.
Hence, this flow doesn't crash anymore
OPW 1837511
closes#24350
The way the calendar view selected its form view was broken for two
reasons:
- any value given in the form_view_id attribute was kept as string,
which means that the string value would be sent to the server, and
this is not good.
- if no value was set, the calendar view then simply did a do_action
with the form view id set to false, which means that the default form
view is used. This is mostly ok, except when we are in the context of
an action with a form view which is not the default one. In that
case, we clearly prefer the form view from the action.
For example, before this commit, the form view in the timesheet
application (community) is not the same as the default form view on
account.analytic.line.
Note that this commit also adds a small tweak to the mock server to
better simulate errors like the web client does (in session.js).
Having boolean checkbox in an editable list
Before this commit, the checkbox was disabled, thus not clickable
The user, who probably expects to click on it to tick/untick
was thus misled, and needed to click *outside* the checkbox in order to activate the row
and only then tick the checkbox
After this commit, the behavior is as expected from the editable list point of view
clicking anywhere in the row (inlcuding on the checkbox itself) activates it into editable mode
OPW 1836067
closes#24292
- Create a binary field which takes some time for computation. For
example:
```
ding_dong = fields.Binary(compute='_compute_ding_dong')
def _compute_ding_dong(self):
if not self.env.context.get('bin_size'):
while True:
3*3
for x in self:
x.ding_dong = x.product_id.image_medium
```
- Run the server with a limited CPU time, for example:
`--workers=2 --limit-time-cpu=10`
- Download the file
A JS traceback occurs, without any information about the real crash.
The error management is simply not working: `JSON.parse` is called on a
string which is not JSON-parseable.
opw-1838832
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
When in Python 3, then function `open` defaults to open the file in text mode
with and the encoding (if not passed) is taken from
`locale.getpreferredencoding`.
Using `getpreferredencoding` is not necessarily a good practice. Because
files might no be encoded that way.
When testing Odoo not in runbot (which has LANG set to C.UTF-8) you may get:
Traceback (most recent call last):
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 24, in test_check_suite
self._check_only_call('web.qunit_suite')
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 37, in _check_only_call
if RE_ONLY.search(fp.read()):
File "/home/gitlab-runner/virtualenvs/odoo11-MlnlRiTaP2/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4757: ordinal not in range(128)
The proposed solution is to read the file in binary mode, and decode to
unicode/str ourselves using utf-8. We don't use the encoding argument of
`open`, so that the code works in both Python 3 and Python 2.
PR #24434
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
Since 11.0, reports could not be edited at all anymore. This is due to
the fact the editor files were refactored but the report feature is not
correctly organized since it was merged with the 'web' app. Indeed, the
'web' app is still calling files and assets of the 'web_editor' app which
is not a dependency (but it is working as 'web_editor' is auto-installed
with 'web').
opw-1826599
opw-1834971
Closes https://github.com/odoo/odoo/issues/24034
Before this commit, when uploading a file as attachment in Safari,
The file icon kept on showing 'downloading' whereas the request was successful
This was because the return from the server had a different UTF-8 norm than Safari
After this commit, it works well
OPW 1836545
closes#24307
Assume a list view with a many2many field, and a record for which
that many2many contains a single value, whose nameget returns the
empty string (which is a falsy value in JS). Before this rev., it
triggered an infinite number of namegets, and the browser crashed.
It was because the cell was re-rendered when the nameget returned,
and in the rendering of the cell, it re-performed a nameget if
the value was falsy.
opw 1838255d
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
In some situations, it could happen that the action manager had a
rejected deferred representing the creation of a view, and was blocked
from doing any other interaction with that view.
For example, imagine that a read operation crashes for record 1 on the
model res.partner. If the user is on the kanban view and click on
record 1, there will be an error dialog informing him of the error.
However, if the user clicks then on another record, nothing will happen
because the action manager is blocked (only the form view in this case).
With this commit, whenever the view creation process failed, we also
remove the rejected deferred so the action manager will be allowed to
try again.
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
Currently, the default field widget of type html is not defined in the
web addon, but in the web_editor addon. It uses the summernote library
and different assets.
The web_editor addon is defined with auto_install=true, so it is usually
not an issue. However, it could happen that there is some issue with
the web_editor asset bundles. In that case, any form view with a field
of type html will crash.
With this commit, we define a default widget of type html in the web
addon. This will render as text (so, not exactly what one might
expect), but it is still better than making the web client unusable.
Christophe Simonis