Commit:
https://github.com/odoo/odoo/commit/818c18e55d0718286ff5bf332186a10f4d7a58ef
Updated the resequence logic in a way that was almost falser than before.
The added test however did work by coincidence, as index values were equal to
the sequence field values.
To be sure that we synchronize with what happens on the server, we do a read
after the resequence.
Additionnally, we take into account the result of the server resequence return;
if it is false, it means no resequencing happened, so we should not do a read.
opw 1867049
closesodoo/odoo#27184
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
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
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).
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 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.
Before this commit, some breaking spaces were present in the js code.
Such spaces are misinterpreted and worked by luck.
This has become a problem with exported js bunldes (e.g. the
external_lib bundle in im_livechat).
This commit replaces breaking spaces by regular spaces.
Before this rev., sorting groups in list views wasn't supported. It
hadn't been implemented in the new views.
This rev. activates the feature, so groups can now be sorted on
their aggregates again. It also implements a basic (first level
only) sorting in mockReadGroup, in the mock server.
opw 781288
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
With the new views, we mainly focused on making them work. But we also
need to be able to handle unusual cases, such as some RPC failing. An
example of such a problem was the following:
- a form view with a one2many with an onchange
- edit mode, change a field in the one2many, click elsewhere
- the onchange triggers, calls the server
- it may happen that the server fails with a ValidationError
- the onchange deferred fails, the line in the one2many is restored to
the value known by the list renderer, which is the previous value (but
the new value was applied to the model)
- we now have a 'corrupted' state: clicking on save will send the
invalid value, even though the UI displays the previous one.
We solve this problem in this commit by making sure that the onchange
deferred returned by the _performOnchange always succeed (or stays
pending). If the rpc fails, the deferred will succeed with an empty
dictionary. This means that the list renderer will be updated with the
value from the model.
Note that it may not be intuitive that a failure in the onchange is not
seen as an error from the perspective of the _performOnChange, but I
think that it still makes sense:
- the validation/network errors are not really a concern of the UI. The
UI just display the values entered by the user.
- if an onchange fails (for example, because of a coding error), we do
not really want to prevent the user from working.
Also, when the onchange is performed, the initial change was already
applied to the local data. Rollbacking them would be a more difficult
task.
Note that we also improve the mock server in this commit, to allow
mocking failures.
This commit introduces a new way to hide a column in a x2m list view.
The attribute 'tree_invisible' can be add in the field attrs in the x2m
view definition. This attribute can use the 'parent' key to make a reference
to the parent record (e.g. 'parent.id').
When the mockserver handles an unimplemented route, it just log an
error. This is annoying because it does not break the QUnit suite, so
if the developer does not look at the console, it will look like the
test suite pass. However, the runbot will see that as an error.
With this commit, we throw an error to force the test suite to fail in
that case.
The server postproccess the view to add attributes on many2one fields, i.e.
`can_create` and `can_write`, according to access rights.
These attributes are parsed by the client as string but should also be parsed by
the many2one when evaluating them.
The mock server has also been adapted to set these attributes.
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
Before this commit, only the routes which began by '/web/image' were
mocked (simply ignored). This forgot the case were it is a full URL
(http://www.test.com/web/image). Now, also mock the static images
routes (for .png and .jpg).
Some one2many fields are called with a many2many widget to unlink
records instead of delete them. But this behavior was modified with the
new views and the records were deleted anyway.
In this commit, we restore the previous behavior, and create a FORGET
command in basic model
to do that. Note that the widget='many2many' is a hack, and a better way
to accomplish this is to use a new custom option. But this would be a
fix for master (PR #18413)
Before this commit, the _mockNameSearch method of the mock server was
computing by hand the first element of the domain. This was adhoc and
wrong (for example, the '==' operator). Also, we actually have a method
designed to just return the records matching a given domain.
Before this commit, when whe loglevel was set to 2 in the mock server,
we simply logged the parameters in the console, then give the same
object to the _performRpc route. Most of the time, it is not an issue,
but nothing prevents the _performRpc route to modify the args object.
And this happens with the /create route, which is very confusing: when
we have a breakpoint/debugger in the mock rpc function in a test, we see
the correct arguments passed to the function. However, if we look at
the arguments in the console, after the end of the test, we see other
values (for all fields) in the args.args[0] object.
The solution is to simply deep copying everything, so any modification
in the mockserver will not affect the logged object.
Fixes two issues in the test environment:
- for unset fields, the mockRead is supposed to return 0 (numerical
fields), empty array (x2many fields) or false (otherwise). Except
for the first case, it was returning undefined, and this might
cause crashes when evaluating contexts or domains.
- the mock environment allows overriding some global properties
like the session, for the test case only. Once the widget is
destroyed, those global properties are reset to their original
value. This wasn't working for models tests, because the destroy
function of the parent widget was never called. This could make
tests fail as they could have been impacted by other tests.
The previous code loading the tooltip data was sending a null value
to read as id, which resulted in an access error. This behavior was
not observable in the tests because of b8c1571 which was meant to
allow giving inexistant ids to mockRead but also ended up accepting
falsy values, which was not true to the actual server.
In addition, the title of the column was wrong for unset m2o, it
displayed false, the value of the field when unset, rather than
the default "Undefined" title.
When creating a new record, the numeric field default value should be 0 in order
to avoid manually setting mandatory fields to 0.
This behaviour has been removed with the new views but one wants to restore it.
The `mockRead` function has also been adapted in this commit because the server
returns 0 for unset numeric fields.
The mock server had to be modified in order to test this behavior
since it used to throw an error for invalid ids, while the actual
server just ignores it and continues forth with the other ids.
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
Otherwise some changes can create rpc errors that are silently caught
and never seen as long as, out of (un)luck, the end result is the same.
Tests which need to create a server error can just simulate it using
the mockRPC mechanism.
In some cases, the parentID was not properly set, which is a problem
when we need to evaluate the parent in a context.
Note: I also added a better error explanation in the mock server, to
make it better for the developper to see what is wrong.
Before this rev., the _mockReadGroup function only supported
grouping on one field, and if called with an array of fields of
length > 1, the remaining fields were ignored.
Grouping on several fields is now supported, and some tests had
to be adapted.
Even if the `default_order` attribute should be like 'name,id desc,coucou'
we want to support the syntax 'name, id desc, coucou' (i.e. with spaces after
the comma).
The commit also patches the mock server.
We fix in this commit three small issues in the test framework.
1. throw an explicit error when we try to do a fieldviewget in the mock
server with a model that does not exist. This will make it easier to
figure out what went wrong when copy pasting a test from one file into
another, and forgetting to change the model in the createView parameters
2. wrap the result of special methods in the mock server in a deferred,
so we can simply return a value when using that functionality. Also, it
is more consistent with the rest of the mock server
3. for iframes, we no longer change the src attribute to #test:url.
This had the problem of actually loading the page. Instead, we change
it into about:blank and we copy the old url into the data-src attribute for
reference.
- Fix the toolbar behaviour since there is no more dataset in the widget.
- Improve the communication beetwen the controller and the toolbar.
- Move the code linked to the document upload in the right file.
- Adapt the tests to mock the search_read done by ´document´ addon
- Adapt the mock server to be able to give a custom toolbar action
Relational fields with attribute 'invisible' set to true are in
views because they are used in domains or contexts. In this case
their relational data is useless, only their ids matter. Before
this rev., their relational data was fetched anyway. More
precisely, it was the case for many2ones after a default_get, and
for x2manys with inline views, or without view (e.g. with widget
'many2many_tags').
The previous code used to create its own args array
for the search_read method, replacing the one that
was originally given to it.
This lead to silent errors since positional arguments
to this function were completely ignored in the case
of search_read.
I took this commit as an opportunity to improve a
bit on the current state of these rpc helpers.
Namely, the basic args/kwargs priority is the following (top-to-bottom):
- kwargs defined in the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For read_group and search_read methods, the priority is the following:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For the /web/dataset/search_read controller, only the params kwarg is
supported, resulting in the following priority:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- positional arguments are passed as is
If both a kwargs and a positional arg is given for the same parameter,
it will be sent as is to the server which will crash with a typical
"got multiple values for keyword argument" TypeError. However, in the
MockServer however, we give priority to kwargs over args in this case.
Please note that I also chose to remove unnecessary default values so
that the ones actually used are the ones from the server, not the ones
that were duplicating those in the rpc js file.
Before this commit, when we moved from one line to the next, we did not
wait for the unselectRow to end. This means that if the read (from the
unselect row) completes after the default_get, the list renderer was not
in a coherent state (currentRow was set to null), which could (and did)
cause a crash.
This was found by pressing the TAB key a few times, and editing some
values.
Also, we slightly improved the logging in the mock server. Before this,
the responses from the mock server did not show from which route it came
from. But in this test, we specifically make sure that the rpcs
complete in a different order, so it was not really optimal.
Also took this opportunity to refactor the code of pivot to adapt
the parts that were not up to date and remove the useless deferred
in sortRows, courtesy of aab.
The exportData function still needs reworking.
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
len-odoo