How to migrate to the new OfD structure?
⏭️

How to migrate to the new much. OfD structure?


Abstract

Before the 4th of July, until v.17.0, our Odoo fur Deutschland product was located in 1 repository, structured into the following 11 modules : 

  • much-ofd-installer
    • much_ofd_datev
    • much_ofd_german_data
    • much_ofd_german_translation
    • much_ofd_qweb_updater
    • much_ofd_qweb_updater_account
    • much_ofd_qweb_updater_account_inventory
    • much_ofd_qweb_updater_delivery_inventory
    • much_ofd_qweb_updater_inventory
    • much_ofd_qweb_updater_purchase
    • much_ofd_qweb_updater_purchase_requisition
    • much_ofd_qweb_updater_sale

From the 4th of July, starting v.17.0.1.0.0, the OfD product was restructured into 3 products : much. DATEV CSV export, much. German Data & Translation, much. German document templates.

Each product have it's own repository, structured in the following way: 

  • much-german-documents
    • much_qweb_updater
    • much_qweb_updater_account
    • much_qweb_updater_account_inventory
    • much_qweb_updater_delivery_inventory
    • much_qweb_updater_inventory
    • much_qweb_updater_purchase
    • much_qweb_updater_purchase_requisition
    • much_qweb_updater_sale
  • much-datev-integration
    • much_account_datev_export
    • much_account_datev_import
    • much_account_datev_legacy_base
  • much-german-data-translation
    • much_german_data
    • much_german_translation


Guide to migrate 

It is recommended to migrate to the new structure as soon as possible, so it's easier to get the latest fixes and features. To do so, we implemented migration scripts that allow you to seamlessly adopt the new structure.

Customisations to any of the modules are not supported by the standard migration scripts and need a case by case modifications.

To migrate, please do the following : 

Step 1: Prepare the Environment for New Sub-Repositories

  1. Remove Existing Sub-Repository: Delete the old sub-repository from the project.
  2. Integrate New Sub-Repositories: Add the three new sub-repositories to the project. Do not install yet.
  3. Allow System Build: Permit the system to build with the newly integrated sub-repositories.
  4. Identify Inherited Views and Templates: Locate all views and templates in the database that inherit from modules within the old sub-repository 
    • Example: A view named much_qweb_updater_account.report_invoice_document_din5008_much in a dependent module extends a view from an "ofd module."
  6. Delete Inherited Views and Templates: Remove the original views and templates from the database that are the targets of these inheritances identified in the previous step. This must be done before proceeding.
  7. Verify Deletion: Ensure that all identified inherited views and templates have been successfully deleted from the database.
  8. Install New Modules: Install all the new modules that were introduced with the new sub-repositories.


Step 2: Update Dependent Modules

  1. Incorporate Necessary Changes: For all modules that depend on the newly introduced modules, apply the following modifications:
    • Adjust Inheritance IDs: Update the inherit_id in any templates and views that previously extended elements from the old "ofd modules" to now point to the corresponding elements in the new modules.
    • Increment Module Versions: Increase the version number for every module where changes have been made.
    • Update Dependencies: Modify the depends list in each changed module to reflect the new names of the corresponding "ofd modules."
  3. Push Changes: Commit and push these modifications to the relevant version control system.