Manually adding a line should not trigger the computation of the field,
just like modifying the line fields that occur in the field's domain.
In other words, the dependencies of the field should be limited to the
ones declared on field or its compute method.

closes odoo/odoo#71027

X-original-commit: 9000a50582db827ff12acdecf8ef91749122452d
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

With this commit, 2 changes are made to the way that the
fields.Selection.ondelete cleanup action works:

1) We manually delete ir.model.fields.selection **before** the deletion
of ir.model.fields purposefully to **avoid** SQL CASCADE deletes, as we
do not know which selections are deleted in cascade and thus we cannot
perform the corresponding ondelete cleanup action (which is implemented
within the ORM).

2) In some actions, namely 'set default' and 'set null', we write a
"safe" value to the records containing the Selection being deleted,
before this commit this would go through the ORM (records.write()) but
this is problematic if there's a write override for the record's model
that raises an error for the field being written to. With this commit,
we first try to go through the ORM but if there's a failure (because of
the raise in a write override) then we will bypass the ORM and set it
with SQL.

opw-2451126

closes odoo/odoo#67253

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

Consider a constraint method with two fields: a normal field, and a
field with an inverse method.  When calling write() with both fields,
the constraint method should be invoked once.

closes odoo/odoo#64411

X-original-commit: 3b39d7efa94484b3bbf04fce756394a7e424f625
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

This takes a former patch one step further.

Assume you recompute a field on two records, and the computation assigns
the first record but not the second one.  Before this patch, the
recomputation process was accessing the field on both records.  When
accessing the first record, both records are recomputed, and the value
of the first one is found in cache.  When accessing the second record,
no recomputation is made (it has been done already), and the cache is
empty. The field is thus fetched from database, and this crashes because
of insufficient access rights.

This scenario was causing some obscure nondeterministic crashes in
tests. The nondeterminism comes from the choice of the environment for
flushing (it should not be in superuser mode); the order of records in
the set to compute; the order in which records are assigned in the
compute method; the fact that the compute method should assign some
records and some not.

The fix consists in adding a method that processes pending computations,
without doing anything special for unassigned records.  The method is
used in field accessors (__get__ and mapped) and in method recompute().
The access error is gone because the recomputation no longer tries to
get the value of a field to compute.

closes odoo/odoo#64250

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Fixes 3a6ac95 that ignores computation of recursive stored fields during
creation of records.

The problem happens when we have:

* a recursive stored computed field
* an `api.depends` of this field which is a relation to another record

When this "another record" is created and should recompute the recursive
field, it is ignored.

closes odoo/odoo#64031

X-original-commit: 79634eefb225a7aaa6c3c26af126fb69078c22ac
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet (rco) <rco@openerp.com>

When performing the onchange for the first time on a new record, if a
field has a default value, it could be two times in the `todo` field
list to compute.

closes odoo/odoo#63983

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

This fixes an issue that occurs when marking fields to compute in the
following situation:
 - it occurs before the actual modification,
 - a relational field is marked to compute,
 - the same field is traversed to inverse some dependency.

When the marking occurs after the modification, the traversal of the
field should actually recompute the field.  However, if the marking
occurs before the modification, the inversion of dependencies must be
based on the current value of the field.  This is the case with method
unlink(): we call method modified() to mark the fields that currently
depend on the records to be deleted, and the fields must be computed
only after the deletion!

X-original-commit: 3a6ac95ddf6a8719aa714a83fc339ba838c3811d

When a form view is opened, the first call to `onchange` should always
compute fields, even if their dependencies have no default value.  Make
sure it is the case for main records, and for records inside one2many
fields.  The latter case was actually not working as expected.

closes odoo/odoo#63627

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>

Consider a one2many field with a corresponding many2one field that is
computed.  After modifying the many2one field's dependencies, the cached
value of the one2many field is inconsistent until the many2one field has
been recomputed.  Therefore, one has to force the computation of the
many2one field before accessing the cached value of the one2many field.

closes odoo/odoo#59031

X-original-commit: b9201ebdd65eaabab9257cf97c58410681783fa6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>