Fix(Core): fix migration error when container are related to Generico…

[stonebuzz]

…bject Model or Type

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes [BUG] ClassNotFoundError on plugin installation/activation for custom asset class #1042

If a container field is attached to a model or type derived from a GenericObject,

the migration of the container to CustomAssets fails because it does not take the model or type into account.

In GLPI:

• A CustomAsset follows the format: Glpi\CustomAsset\CarAsset
• Its model follows the format: Glpi\CustomAsset\CarAssetModel
• Its type follows the format: Glpi\CustomAsset\CarAssetType

The current migration method does not consider that the container may be attached to a model or type of a GenericObject.

Screenshots (if appropriate):

[stonebuzz]

waiting from community feedback

[stonebuzz]

I’ve added an additional check.

Now, before verifying whether the GenericObject plugin is at the correct version (based on the presence of its table), I first check if any containers are actually linked to GenericObject.

This change was motivated by a support case: the client had generic objects, and the Fields plugin was crashing because the GenericObject End of Life Updater plugin wasn’t enabled — even though no containers were associated with GenericObject.