[FIX] base: reset _rec_name if x_name field is deleted

Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:

    - Install studio
    - Create an app (create a new custom model M)
    - Uninstall studio
    -> Uninstall fails because field display_name of the custom model M
    depends on field M.x_name which has been removed due to the
    uninstall process.

To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:

    - We trigger the uninstall of studio, this triggers the uninstall of
    any modules that depend on it, namely studio_customizations which is
    the module in which all customizations done with studio live in.

    - We gather all data belonging to the studio_customization and we
    start deleting in the following order: ...,
    ir.model.fields.selection, ir.model.fields, ..., ir.model

    - During the unlink process, we first remove the actual fields from
    the model instances before deleting their database reflections, this
    is done in the ir.model.fields._drop_column() method, it is this
    method that will delete the x_name field but **not** the
    display_name field, since it is a base field and not a custom one.

    - After the deletion of the fields in memory, we call modified() to
    mark fields that might've depended on the fields we just modified so
    that they can be recomputed later.

    - The call to modified will in turn access field_triggers, but since
    we're in a new registry and field_triggers is a lazy property, it
    will be computed right at this moment, this means that it will call
    resolve_depends on the display_name field which still exists, and
    this field has a dependency on the x_name field that we just
    deleted! This is what will trigger the crash.

With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:

    - Before the aforementioned commit, the field_triggers attribute was
    computed during the registry's setup_models(), in the case of an
    uninstall this call to setup_models was done way before the
    uninstall step of the registry (Step 3 is the last to call
    setup_models before Step 5).

    - This means that the old behavior was technically a bug, because
    right after removing x_name from the model, the field_triggers still
    contained a dependency from display_name to x_name, the former being
    no-longer present in memory.

With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.

opw-2452498
opw-2478589

closes odoo/odoo#67747

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

0 files changed, 0 insertions, 0 deletions