When there is a materialized view that has not been populated any select
on it will fail.

Example of traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
    registry.setup_models(cr)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
    env['ir.model']._add_manual_models()
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
    cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT:  Use the REFRESH MATERIALIZED VIEW command.
```

Several upgrade requests have or had had this error which has been
solved with specific scripts.

Related to #40930

closes odoo/odoo#71002

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

We have observed that in some circumstances, there is no field to
reflect on a given model.  Avoid an exception in that case.

closes odoo/odoo#70774

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)

Consider a model M with a one2many field with comodel L, such that
deleting records in M cascade-deletes records in L.  Import a bunch of
records in M with one2many lines having specific external ids.  Delete
the imported records: the database cascade-deletes the corresponding
lines, but the lines' external ids are not deleted.  Now re-import the
same records: this crashes, because the import process finds the lines'
external ids and tries to update the deleted lines!

The fix consists in checking that an external id's record actually
exists.  The existence check was removed for performance reasons by
https://github.com/odoo/odoo/pull/26496.  We reintroduce it by resolving
the external id with a join on the model's name, which checks the
record's existence faster than an extra query.  This patch allows to
re-create the imported records' lines.

Another patch is necessary to actually update the external ids that
refer to deleted records, otherwise they remain dangling, and importing
the same records again duplicates the lines, because their external ids
do not match any existing record.

OPW 2409649

closes odoo/odoo#63077

Related: odoo/enterprise#15202
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

In case a user has installed a module where the code becomes unavailable or during migration a module was removed and needs to be removed after migration it is impossible to uninstall the module from a database still holding the fields or the models.
In order to disable prefetch based on information from the database it is needed that the module and models of the unavailable module are initialized with related fields and models.

closes odoo/odoo#62892

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

During the uninstall step of the registry, we perform a commit right
after the uninstallation of all module data, this commit is performed
right before the creation of a new registry, this means that said commit
will call `flush_env` and thus `recompute` on an environment that is
based on a stale Registry (memory and database are unsynchronized).

This means that during this specific moment, there's a chance that the
recompute function may have to fetch some fields it depends on to
perform its computations if said fields are not in cache, this in turn
means that it will try to prefetch fields that are potentially no longer
in the database, making the registry crash and preventing the uninstall.

This is what happened with multiple if not all `payment_*` modules, the
main module `payment` depends on a `ir.module.module` record, most
notably the `color` field of the `payment.acquirer` model which depends
on the `state` field which in turn depends on the
`ir.module.module.state` field.

This meant that uninstalling a module such as `payment_paypal` triggered
a recompute of `payment.acquirer.color` during uninstall, and to perform
that computation we need several `payment.acquirer` fields to be fetched
from cache or the database. If in cache, the uninstall would go through
without a hitch, if not in cache, we would fetch the required fields
from the database but we'd also attempt to prefetch the fields
introduced by `payment_paypal` that had just been deleted from the
database!

To avoid this, the `_module_uninstall_data` method of `ir.model.data`
will henceforth guarantee that `ir.model.fields` that are to-be-deleted
will have their prefetch set to False, meaning only existing fields will
be fetched from the database during the uninstall of extending modules.

Fixes #60424
opw-2372598

closes odoo/odoo#62246

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

When removing custom models from the registry, one also has to remove
indirect references to those model.  One such reference is the name of
the custom model in its parent models' `_inherit_children`.

Not removing that reference causes a crash when one of the parent models
is extended: the parent model will make its children models recompute
some of their attributes (see method `_build_model_attributes`).

closes odoo/odoo#62002

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

After commit 06a8c5264eb6e87c29ad1d23a14e12dd45aa281c it is no longer
possible to pass bare modules to `safe_eval`'s context, however during
the aforementioned commit only the wrapped datetime and dateutil modules
were updated in ir_model's SAFE_EVAL_BASE context, thus the bare `time`
module was still being passed (and this triggered a traceback whenever a
custom computed field that used the time module was computed).

The fix is simple: pass the wrapped time module to the `safe_eval`
context instead of the bare one.

This commit also introduces a regression test to verify that the passed
modules actually work in custom fields.

opw-2347711

closes odoo/odoo#59496

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

Co-authored-by: Xavier Morel <xmo@odoo.com>