Odoo/odoo/addons/test_new_api/views/test_new_api_views.xml, branch 14.0 The current checkout of upstream Odoo [FIX] core: invalidation of computed editable field in one2many 2020-12-02T11:45:17+00:00 Laurent Smet las@odoo.com 2020-11-20T08:00:31+00:00 5279a08a005bacee4ecd76cc189d8ce65c8e600c This fixes the issue introduced by revision fd50ba9fb838067fab0b920470cf79b9c94d785c The way computed fields are invalidated depends on the order of the dict passed as a parameter to method onchange(). This causes some unexpected behavior when dealing with computed editable fields: the user loses the value in that field because of the onchange. Explanation: during the onchange, the modified field is cached by record._update_cache(changed_values, validate=True) If the field is a one2many, 'value' contains an update command for each modified line. Because of 'validate=True', the assignment triggers field computations on the lines, which are already handled by another call to onchange(). In case anything on the parent model modifies some line, the whole one2many values are returned to the user, and accidentally recomputed fields show up in the interface. closes odoo/odoo#62060 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> 
This fixes the issue introduced by revision fd50ba9fb838067fab0b920470cf79b9c94d785c

The way computed fields are invalidated depends on the order of the dict
passed as a parameter to method onchange().  This causes some unexpected
behavior when dealing with computed editable fields: the user loses the
value in that field because of the onchange.

Explanation: during the onchange, the modified field is cached by

    record._update_cache(changed_values, validate=True)

If the field is a one2many, 'value' contains an update command for each
modified line.  Because of 'validate=True', the assignment triggers
field computations on the lines, which are already handled by another
call to onchange().  In case anything on the parent model modifies some
line, the whole one2many values are returned to the user, and
accidentally recomputed fields show up in the interface.

closes odoo/odoo#62060

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
[FIX] test_new_api: Fix bad shared cache usage for stored computed fields 2020-08-04T15:01:45+00:00 Yannick Tivisse yti@odoo.com 2020-07-08T13:26:27+00:00 62355b6ad3e2af16efabe1c3ca2fb053a6084bc1 Purpose ======= Since the 13.0, a regression has been introduced in hr_timesheet. Considering: - The account.analytic.line model, representing a timesheet entry - The project.task model, representing a task, on which we have the fields: - timesheet_ids: One2many - planned_hours: Computed (sudo), stored, representing the sum of the timesheet amounts - An ir.rule restricting the timesheets CRUD to his own only. A user can only see its own timesheets on a task, but the field "Planned Hours", which is stored-compute_sudo, should take all the timesheet lines into account However, when adding a new line and then recomputing the value, no existing line from another user is binded on self, then the value is erased and saved on the database. Specification ============= This commit introduces a test that illustrates that bad usage of a shared cache. A correct way to fix this could be to avoid using the cache if an ir.rule is pointing to the related model. That would force the recomputation in a real sudoed environment. closes odoo/odoo#55408 Taskid: 2285924 X-original-commit: 50e229fe66b2a82717d4260287e18a875bbd26f5 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com> 
Purpose
=======

Since the 13.0, a regression has been introduced in hr_timesheet.

Considering:
- The account.analytic.line model, representing a timesheet entry
- The project.task model, representing a task, on which we have the fields:
    - timesheet_ids: One2many
    - planned_hours: Computed (sudo), stored, representing the sum of the timesheet amounts
- An ir.rule restricting the timesheets CRUD to his own only.

A user can only see its own timesheets on a task, but the field "Planned Hours",
which is stored-compute_sudo, should take all the timesheet lines into account

However, when adding a new line and then recomputing the value, no existing line
from another user is binded on self, then the value is erased and saved on the
database.

Specification
=============

This commit introduces a test that illustrates that bad usage of a shared cache.

A correct way to fix this could be to avoid using the cache if an ir.rule is pointing
to the related model. That would force the recomputation in a real sudoed environment.

closes odoo/odoo#55408

Taskid: 2285924
X-original-commit: 50e229fe66b2a82717d4260287e18a875bbd26f5
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
[IMP] core: do not recompute stored field on new record 2020-03-23T09:04:59+00:00 Raphael Collet rco@odoo.com 2020-03-10T16:33:05+00:00 fd50ba9fb838067fab0b920470cf79b9c94d785c The use case is a cache miss of a stored field with compute on a new record with origin. The field should be computed only when explicitly triggered, i.e., when a dependency has been modified. Otherwise it should be fetched from the origin record. closes odoo/odoo#47353 Signed-off-by: Raphael Collet (rco) <rco@openerp.com> 
The use case is a cache miss of a stored field with compute on a new
record with origin.  The field should be computed only when explicitly
triggered, i.e., when a dependency has been modified.  Otherwise it
should be fetched from the origin record.

closes odoo/odoo#47353

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
[IMP] base/test_*: Adapt tests to work with/without demo data 2019-11-05T12:08:02+00:00 Yannick Tivisse yti@odoo.com 2019-11-04T15:22:50+00:00 4aa5ba35afa949098d532189beb4c680dcada2fa