OpenUpgrade service module features
Specificy the features of the OpenUpgrade service module. This module can be installed on an upgraded database to perform specific tasks that finalize and report on the migration
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Perform migration tasks that for technical reasons are hard to do at upgrade time. Specific examples:
- Write defaults on the ir.attachment model. This is hard to do as the model needs instantiations of the models that the attachments are linked to, which are not available when the base module is upgraded. UPDATE: this could instead be taken care of by a separate, deferred stage in the migration. Something like that popped up in the 7.0 edition, which needs to sync commercial partner fields after all the modules have loaded.
- Display module state. Modules that are still set to 'to upgrade' could not be loaded and should be reviewed. Their existence could either indicate an incomplete migration or their own obsoleteness. The administratorshould be able to remove such modules easily from within this screen (= set status to 'to remove' + database upgrade).
- Gather obsolete columns and tables from the database. Offer this list to the OpenERP database administrator and allow him to purge the database after review.
- Also propose to delete accompanying records from ir_model and ir_model_fields and warn which tables/records are affected by foreign key constraints to those tables. (This is basically finding out where references to obsolete tables/fields are hidden)
- Perform a required field analysis. Offer a list of references with resources that lack values for required fields to the OpenERP database administrator so as to allow him to supply the data (ideally with the option of mass updates).
- Generate an overview report of the upgrade process, gathering the user_notes from the migrations directories together with the time of the module upgrades. The user_notes should be injected in a dedicated table by the openupgrade migrate() decorator.