When invoking onchange() on a line in a one2many field, the inverse
many2one field is given as a dict of values.  Those values are the ones
of the "container" record in the form view, and they include the "id" of
the container record.  The method onchange() instantiates the container
record as a new record with the given values.  Fix the code to set the
expected "origin" of that record to the record with the given "id".

closes odoo/odoo#71474

X-original-commit: ebfb5d90fd4ff65ee1d2fc73faf8f9eaa18f4521
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>

Previously, an ondelete policy would be assigned to any required
Selection fields, the default policy being 'set null'.

Base fields do **not** require an ondelete value, since if they are
deleted there is no "data fix" to apply because the field's column is
dropped, and in fact it's error-prone to do so because during
`_process_ondelete`, the system would attempt to set to null fields that
were required (i.e. NOT NULL).

This issue is hidden by the fact that ir.model.fields are usually
deleted **before** ir.model.fields.selection and thus the ondelete
action won't be applied on the field with the original definition
(because it has probably been deleted by SQL CASCADE)

When a record is written on a computed field with an inverse method and
an x2many field wit a delete command, the computed field is not properly
handled by the inverse method, because of a whole cache invalidation
that happens during the unlink.

With this commit, we write in cache on the fields that have been
invalidated before invoking the inverse method.

opw #2439861

closes odoo/odoo#67152

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

When comparing the values of a new record with its origin, x2many fields
are always different because we compare new records with real records.
For instance, converting the value of a one2many field where lines have
a many2many field always returns update commands for the many2many
field.

closes odoo/odoo#66937

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

This guarantees the cache consistency of the many2many field values.

X-original-commit: 74e188197e560897e13f7666d385a45ed7ca6f90

When using command "6" (SET), the one2many field's inverse was not
assigned on the lines.

closes odoo/odoo#65656

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

When retrieving company dependant values, the computed domain called
search_multi method of ir.property as normal user.
Since odoo/odoo@8f578637076d4b65 ir.property records are no longer
readable by a normal classical user.

To reproduce:
Add a domain using a company_dependant field
e.g. on res.partner, with purchase installed, modify the parent_id
field in form view to

  <field name="parent_id" ... domain="[('property_purchase_currency_id','=',property_purchase_currency_id)]" />

When clicking on the parent_id with a low priviledge user, an
access-right error is raised, as the user doesn't have access to
ir.property records

Fixes odoo/odoo#65450

closes odoo/odoo#65552

Signed-off-by: Martin Trigaux (mat) <mat@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>