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>

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>

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 model with a field F and a computed editable field G that
depends on F.  Assume we open a form view, and both F and G have a
default value.  The first onchange should return F and G with their
respective default values.  In other words, the field G should not be
recomputed even if its dependency F was assigned a default value.

The use-case that showed the issue is batch payments.  When adding a new
payment in the one2many field of a batch, the new payment should use the
batch's payment method by default.  The default value for the payment's
method is assigned by context on the one2many field in the view.  Before
this patch, the new payment's method was given by the computation of the
field, and its default value was ignored.

Side note: another test was fixed, but that's because the test was not
consistent with the way Odoo 14.0 manages defaults and onchanges.