The 'Expand All' feature was tested, but in the test environment
RPCs are mocked, and everything is synchronous (by default). So
even if the tests passed, the feature actually didn't work because
of a deferred (the reload deferred) that wasn't waited for.
Keys 'pivot_measures', 'pivot_col_groupby' and 'pivot_row_groupby'
can be specified in the context and are meant to be used by pivot
views to determine the initial measures and groupbys. Before this
rev., the new implementation of the pivot view simply ignored them..
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.
Keys 'pivot_measures', 'pivot_col_groupby' and 'pivot_row_groupby'
can be specified in the context and are used by pivot views to
determine the initial measures and groupbys. There were typos in
some of them in this sale_timesheet template.
Before this commit, the save method in the basic model did not properly
react when the rpc fails. In that case, the returned deferred stayed
indefinitely in the 'pending' state. This is a big problem, because the
basic controller put that deferred in a mutex. As a result, every
subsequent operations (including field changes!) were indefinitely delayed.
To reproduce the issue, you can find any form view where some python
business logic will cause a fail in some cases. For example, create a
new inventory adjustement, click on 'Start inventory', then add a line
in the x2many with the same product as another line. Saving that record
will fail, but then, the form view is broken: no interaction will work.
Before this commit, row decorations were only computed at the initial
rendering for a list view, then never recomputed. Most of the time, it
is not an issue, but list view can be edited, and in that case, it may
be a problem. With this commit, we just override the confirmChange
method to recompute the various decorations.
Note that in bonus, decorations now works in realtime, when editing a
list view (in saas-15, they simply did not work when editing a record)
Also, we now use the same evaluation context as everything else in the
web client: the eval context from the record, not some custom handmade
context like before.
Eval contexts are not easy... They should be different when sent to the
server and when evaluated in the web client. In this commit, we fix
some small issues:
- when evaluated on the web client, x2manys should be a list of ids,
when sent to the server, it should be a list of commands
- dates should be converted to string
- always add current_date in the evaluation context, as a magic key (it
was previously only available in row decoration context evaluations)
PURPOSE
=======
Currently we can choose to load the xmlid of a menuitem if web_tour is installed by setting the attribute `load_xmlid=True` on the view.
This is strange for 2 reasons:
- Searching all the ir.model.data on menuitems with load_xmlid=True to compute its xmlid, searching the related subtree on the returned structure of the method load_menus is quite complicated for the perfomance gain (if there is any perfomance gain to do it)
- This is not working in community in frontend, as only the root menuitems are loaded, thus it is the `load_menus_root` instead of the `load_menus` that is called. This issue prevent a tour step to be displayed correctly on community and enterprise on a menuitem.
SPECIFICATION
=============
Remove all the `load_xmlid` attributes and the related mechanism and move it into base to always load the xmlids for all the menuitems. It won't bee to heavy as the result is cached.
It's better the keep the current mechanism (Load the xmlids from ir.model.data and insert them into the tree) as we only make 1 search to the ir.model.data
Here is what could happen before this commit: open a record (let's say
project.task) in form view. Then, on the sidebar (actions), choose
Merge Selected Tasks), choose a task, and click on Merge. What happens
next is a traceback.
Here is a more precise description of what happened:
- the formview dialog for the merge action closes, which triggers a
reload for the main formview
- the merge action returned an action description for an act_window
- the action manager instantiated a new viewmanager and prepare the form
view, which is an async operation (need to load some data to display
the form)
- the previous view manager (initial one) completes its reload, which
makes it rerender the view, which triggers a DOM_updated event
- the new view manager see this event, and tries to call getScrollTop on
the current view controller, but there are no controller yet, it is
not ready.
We could argue that some of these events should not happen (for example,
if we will open a new view manager action, why do we reload the current
view manager?). But solving these issues is a more deep architectural
problem (we probably will rewrite the actionmanager/view manager layer
at some point).
It could also be argued that in any case, the method getScrollTop should
not crash (same for setScrollTop). Sadly, these methods are fragile,
because some changes in the loading behaviour of a view may break them.
So, in any case, protecting them against unexpected traceback is a
worthwile investment.
With this commit, we just slightly improve list benchmarks, to make them
go through a wider variery of code.
Since we aim to use these benchmarks to track changes in performance
through various versions, it is useful to have a good version in
saas-16.
When we are on a partner form view, we get the total invoiced containing
the child contact of the current partner. But when clicking the button
we only see the invoices of exactly the current partner.
In most locations of the code this has changed (since 347c784da) and
this part should also contain the descendants contacts.
opw-744929
closes#17188
In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".
This caused issue when fetching and posting message with the composer.
opw-744405
closes#17179
-> Move Subtasks mechanism from hr_timesheet to project.
-> Various functional improvements:
- Add new 'Sub-tasks' setting and 'Sub-task Project' field based on
this setting.
- Relabel 'Team Collaboration' section to 'Task Management'.
- Remove 'Customer Satisfaction' section and move setting
'Rating on Tasks' into 'Task Management' section.
- Add customer name on the project's kanban view.
- Set default value of 'Sub-task Project' field is the same project.
- Add 'Parent Task' stat button on task form view.
- Make 'Sub-Tasks' stat button visible when no parent task
Before doing an onchange in a x2many, the basic model tries to evaluate
if the line is valid or not. In that computation, we used the
field.required property instead of using the required modifier. This
commit had to move the modifier handling from the BasicRenderer to the
BasicModel, in order to use it in the _isX2ManyValid method.
Revert "[FIX] account: reset the move reference on bank statement"
This reverts commit 6de2990f8d.
The previous patch was removing the reference of the move.
However, the reference is useful to reuse the name if the line is reconciled
again.
Instead, remove the constrain. To delete the move, account_cancel is already
needed. It is useful to allow removing statement lines to match the statements
form the bank and the one on Odoo.
In the future, allowing to set the amounts to zero should be added as a way to
correct the lines.
opw-741205
In the extended template `HiddenInputFile` there are actually two inputs
(one for image only and another one).
This widget needs to replace both of them otherwise the file selector will
be opened twice.
This rev. fixes the next three bugs:
- the dataPoints representing each group didn't have the parentID
attribute set
- when quick creating a record, the res_ids and count attributes
of the group, and of the parent weren't correctly updated
- when quick creating a record, the environment (view_manager)
wasn't correctly updated
The combination of thoses bugs produced the following crash. Open
a grouped kanban view (e.g. project.task), quick create a record,
open that record in form view (note that the pager was wrong, it
indicated 0/x, where x number of records), delete the record ->
the form is supposed to load the next record, but it
crashed because it couldn't get its id (trying to read id null).
Before this rev., the dashboard wasn't rendered correctly when
the same action (same action id) was several times in the
dashboard.
For instance, if the dashboard contained the list and kanban view
of an action, both views were rendered in the same block, leaving
the other one empty. Moreover, (un)foldeing one automatically
(un)folded the other one.
This was because the action id was used to identify each view, but
this id is not unique in the dashboard. We now use a generated id
instead, which is unique.
Before this commit, it was not possible to set the 'html' widget
for a field in Studio.
Even if this is the default widget for the form view, it not the
case for the kanban view. You need to precise each widget you
want to use (for performance reasons).
opw-744254
- Set-up multi-currency with the following rates:
MXN: 1.0
USD (2017-04-10): 0.052632
USD (2017-04-27): 0.051680
- Create an invoice of 1779.55 USD on 2017-04-10
- Register a payment of 1779.48 USD on 2017-04-27
- Set the invoice as fully paid
It is impossible to validate the payment because of the following error:
"The amount expressed in the secondary currency must be positive when
account is debited and negative when account is credited."
We make sure to align the writeoff amount sign with the writeoff amount
sign in the company currency.
opw-741520
The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....
The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)
This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.
opw-705902
opw-741305
The structure of the product.{product,template} form is the following:
product.product_template_form_view* (both)
|-- product.product_template_only_form_view* (template)
| \-- stock.product_template_form_view_procurement_button
|
|-- product.product_normal_form_view* (product)
| \-- stock.product_form_view_procurement_button
|
\-- stock.view_template_property_form (both)
Previous view was adding weight, volume fields on both view with a attrs that
applies only to the product.template (display only if no template).
This means that the weight was not displayed on product.product form if opened
from a Many2one (using the default product.product view) while the attrs should
not hide it.
Closes#16541Fixes#16428
In a scenario with the following views:
Mod A, view 1*
|-- Mod B, view 2
\-- Mod B, view 3*
view 3 can not rely on the elements added by view 2 in xpath
If view 3 is a primary view, view 1 must be fully resolved first (apply view 2)
before resolving view 3.
Next commit describes a real use-case with product.
Linked to #16541 and #16428
Previously, it used to reload its data when the user clicked
multiple times on save, even though there were only changed
fields during the first initial save, all the other queued
ones have no changes at all and, as such, should not trigger
additional reloads.
Previously, it was possible to click multiple times on stat
buttons while still waiting for the result of a previous button
click. This could end up with the web client in strange states
or, worse, lead to tracebacks. Because of this, we decided to
disable the buttons once one of them is clicked and restore
them afterwards.
By doing this, we encovered a place in the code where a failed
deferred would not be properly forwarded back to the caller,
which meant, in our case, that the buttons would not be
enabled back in case the action failed. This is now fixed.
Initial methods to fix this issue used to break the test below.
Because the label of the assertion this used to break was
contradictory with the value it was actually expecting, we
decided to fix it as well.
Previously, the buttons were not updated properly after discarding
from an editable list view. The user was stuck with "Discard" even
though there was nothing to discard anymore, and he could not create
a new record either since the "Create" button was invisible.
This was fixed by 3aad756. I originally did a different fix which
has since been rendered useless, but the tests I wrote are still
meaningful since they are testing a different case than the commit
which fixed the issue.
Nicolas Martinelli