Reputation: 11223
I have some modules which expand add-ons of Odoo. For example, models in my_module
which expand crm
:
class Lead(models.Model):
_inherit = 'crm.lead'
# exmaple fields
field_1 = fields.Char(...)
field_2 = fields.Many2one(...)
# ... field 99
class Stage(models.Model):
_inherit = 'crm.stage'
# exmaple fields
field_1 = fields.Char(...)
field_2 = fields.Many2one(...)
# ... field 99
The same situation is for modules which expand hr
, product
, etc.
I need to make some changes to the models. For example, in my_module_1
, I need to change a couple of fields(type, relation), in my_module_2
, just to remove a few fields etc. Of course I also need to change views of each module. And of course I have my custom models which have dependencies with models from different apps/modules. But I have data on production which must be stored.
I did not find any information about migrations(or synchronization of modules) in Odoo.
My question is: What is the best way to update modules/apps on production(if we have many changes in fields of models and views)? Thanks in advance.
Upvotes: 20
Views: 4913
Reputation: 3747
My question is: What is the best way to update modules/apps on production(if we have many changes in fields of models and views)?
While this question has been around for a while I cannot see any canonical answer therefore here are my two cents.
The problem of migration from one version to another in Odoo is rather common and definitely complicated. With that in mind the OpenUpgrade project has been created. OpenUpgrade is basically an upgrade path
that will help you transform your data and models from version A to version B. For example if a field named fieldA has had its type changed on version 9 and you are on version 8, OpenUpgrade will take care of this by doing the necessary transformations.
OpenUpgrade also gives you the possibility to create your own migration scripts that will do whatever needs to be done in order for your module to be forward ported (or back ported) in various versions. For the standard modules these scripts have already been written to an extend, but for your own you might need to do some writing.
I suggest that you take a look at the documentation above, this is basically your first stop when we talk about migrations in Odoo.
Upvotes: 2
Reputation: 11223
Maybe there are some tools for migrations in Odoo enterprise version, but I haven't found any information about this. So the solution that I use is to do everything manually. Step by step, attentively. If you know a better way let me know.
For example. If we need to remove some fields:
If you need to change the type/relation of fields:
Be careful when you change relations(one2many, many2many). Make dumps and versions of apps. Check your modifications on local machine with db from production for a couple of times.
One more thing about new fields with relations. For example I have module_1 which depends on crm. module_2 which depends on module_1 etc. I need to add some fields to crm models and show them in module_1. In module_2 I need to show new fields from my custom models in module_1.
We can add all the new fields to models and views in our modules. Stop the server and run the server with the parameter --update like this:
./openerp-server --update=all
In this case all the modules will be updated. If we need to update only the modules which depend on crm we need just to update crm:
./openerp-server --update=crm
Upvotes: 0
Reputation: 788
As per your example, I believe that you already know how to add a new field to an existing model.
I still do not understand why anyone would want to remove a field from an existing model - this is/will be more trouble than it is worth (if there is a valid reason, please let me know). This also applies when attempting to recast field types. With this said, you can quite easily remove/replace/hide an existing field on a view, which should in essence achieve the same outcome.
https://www.odoo.com/forum/help-1/question/add-remove-fields-to-inherited-custom-module-72945
<record model="ir.ui.view" id="enter_an_id_here">
<field name="name">some.text.here.form</field>
<field name="model">crm.lead</field>
<field name="inherit_id" ref="crm.external_id_here" />
<field name="arch" type="xml">
<field name="name" position="after">
<field name="your_field_name"/>
</field>
</field>
</record>
You also talked about migrating data from dependents to another model via copy/paste. This should not be required as you can simply access the data in the existing model through a direct object/field reference, or by using a related field.
new_field = fields.Char(string='String', related='product_id.name')
or inside python
value = self.product_id.name
I will not address anything to do with installing the module/server side commands as the other answers here have already addressed these aspects.
Upvotes: 0
Reputation: 53
Restart the server from the command line once with the -u and -d flags eg.
sudo service odoo stop
/path/to/odoo/odoo.py -d <your_db_name> -u custom_module1,custom_module2
If you're dealing with a production server, I would test this locally, on your development machine with a fresh dump of the production DB make sure it works, tweak it if needed (eg some fields might need defaults, whatever), test it again on yet another fresh dump, until the point that all I need to do is restart the server as above to make the changes happen. Once that happens, back up the database, datastore and even the affected modules on the production server, upload the new module(s) and restart the production server as above (no dumping databases from test to production here) the module update should take care of database changes.
If you're trying to change the structure of a table considerably (eg changing fields datatype) and retain data in tables the only way I can think of doing this is to create add NEW fields first with the new datatype, populate them with data from old fields (either directly with postgres queries or within your "interim version module") and this really depends on the changes, a change from selection to many2one involves inserting selection values into a new table, two very different things from the database point of view the actual field type on the table will be a integer, the ID from the row that holds the selection value in a relational table...
Once your new fields are populated, make the final version of the module removing all the fields you no longer need (keep the other version for the production database).
I would probably test the database population manually on the development server first either in postgres or with some tool like pgadminIII, but plan on creating a script for doing it on the production server (or better yet build it all into the new module version) as it will have to be down while that happens.
I would also look at my postgres tables after it's all done, some fields might still be there even if the new module doesn't use them.
Sorry, I don't know of any simpler, more automatic way of doing it, there just is too many variables...
Upvotes: 0
Reputation: 591
First you have to dump the production database and then restore it in your local system.
Once restored in local system, develop your custom modules to expand the existing model features.
Install the developed modules in local system(restored database) and see the changes you made. If everything is perfect with existing data, then Install that module in production database.
To dump the production database execute the below command in postgres. Command : pg_dump dbname > outfile Example : pg_dump prod_db > prod_db.sql
Before restoring the database, you have to create fresh database in your local system. To create fresh database execute the below command, command : createdb --owner owner_name --encoding utf-8 dbname Example : createdb --owner odoo --encoding utf-8 prod_db
To restore the production database execute the below command in postgres. Command : psql dbname < infile path Example : pg_dump prod_db > prod_db.sql
Upvotes: 0