Skip to content

[18.0][MIG] odoo_project_migration#141

Draft
sebalix wants to merge 28 commits intoOCA:18.0from
sebalix:18.0-mig-odoo_project_migration
Draft

[18.0][MIG] odoo_project_migration#141
sebalix wants to merge 28 commits intoOCA:18.0from
sebalix:18.0-mig-odoo_project_migration

Conversation

@sebalix
Copy link
Copy Markdown
Collaborator

@sebalix sebalix commented Apr 3, 2026

No description provided.

sebalix and others added 28 commits April 3, 2026 19:58
Module integrating the migration data (provided by
'odoo_repository_migration') in Odoo projects to help the analysis of
migration projects.
This new data model is here to distinguish available upstream modules
and installed modules in a project.

It inherits from `odoo.module.branch` so it has access to all its data,
but is linked to an `odoo.project` and has its own `installed_version`
so it becomes easy to find modules that could be upgraded within a
project.
This change allows to get a module `x` present in different
repositories (unicity constraint on `odoo.module.branch` has changed
accordingly). This is useful in case two projects have `x` installed but
the code of these modules (that can be different) are hosted in their
own project repository.

Therefore, the scan of repositories and project modules import have been
adapted to fullfil this new possibility.

Features:
    - allows multiple instances of `<odoo.module.branch>` records
      sharing the same module technical name and branch but belonging to
      different repositories,
    - repositories have now a new `specific` flag, propagated to their
      modules.. By default they host generic modules, but project repositories
      will host specific modules that cannot be shared to other projects,
    - a generic module cannot depend on a specific module
    - when importing modules in a project, specific modules of other
      projects cannot be mapped,
    - once a specific module is scanned in a project repository, relevant
      orphaned modules installed in a project will be re-mapped to this newly
      created specific module,
    - detect PR only on generic modules (unmerged/pending modules are
      generic only, specific modules have to be found in project
      repositories).
E.g this allows to cross modules common to different projects, to
share the costs between them regarding a migration.
when a repo is not collected for migration data but a module
exists in the target version, its state should be "available"
instead of "migrate"
…ories

This supports the migration scan for modules that have been moved to
another repository.

This commit also adds new technical flags and migration states to
improve module qualification during a migration:
    - Moved to standard
    - Moved to OCA
    - Moved to generic repo (specific modules moved to generic repo)

Migration with such states won't trigger a migration scan as modules
could be different. E.g. 'l10n_eu_oss' Odoo module is not the same than
OCA one starting from 15.0, and OCA renamed its module 'l10n_eu_oss_oca' from
this version, either to complete std implementation, or to propose
another one. So these states will help integrators to identify such
modules.

Later we could add a feature to set a given module as renamed from a
given version, like 'l10n_eu_oss' renamed to 'l10n_eu_oss_oca', so the
module won't be qualified with 'Moved to standard' state as it's just a
renaming. But such feature will require to also improve 'oca-port' to
handle such case to perform a migration scan.
…laced for next Odoo version

Adapt odoo_project_migration accordingly, and show this info in CSV
migration report.
@sebalix sebalix added this to the 18.0 milestone Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants