Odoo Descriptor File

In this tutorial we will be going through one of the important files in Odoo, __openerp__.py which is called manifest or descriptor files. In case Odoo10 and above this file is renamed as __manifest__.py because of the change from openerp to odoo but the content will be same.

PS :This file was called __terp__.py when Odoo was known as TinyERP.

We will be using the Odoo9 as an example and will explain all the parameters used in manifest file.

We will be going through how a descriptor file is created and what are it's uses and all the important parameters in the file. And finally we will look into Odoo code structure to analyse what exactly, odoo do with this file.

Basically the descriptor file holds all the information about the module, from module name to all the xml and js files. So this is like a metadata of the module. Every module must contain this information in order to be installed. It declares files that will be parsed during the initialization of the server, and also to determine the different dependencies of the module. This file contains a single Python dictionary, each dictionary key specifying a module metadata.

Below are the basic parameters of the manifest file.

                            
                            
//Odoo descriptor file options
# -*- coding: utf-8 -*-
{
'name': 'Name Of Module',
'summary': 'short_description',
'version': '1.0',
'description': 'reStructuredText_description',
'author': 'VishnuArukat',
'website': 'https://vishnuarukat.xyz',
'license': 'AGPL-3',
'category': 'Uncategorized',
'depends': [ 'base' ],
'data': [ 'security/module_name.xml', 'security/ir.model.access.csv'],
'demo': ['demo/demo.xml'],
'auto_install': False,
'maintainer': 'OpenERP SA',
'application': True,
'installable': True,
'sequence': 10,
'css': [ 'static/src/css/style.css' ],
'images': [ 'images/src/img/image.png' ],
'qweb': [ 'static/src/xml/template.xml' ],
'test': [ 'test/test_file.yml' ],
'external_dependencies': { 'python' : ['ldap'] },
'pre_init_hook': 'function_name', //optional
'post_init_hook': 'function_name', //optional
'uninstall_hook': 'function_name', //optional
}
//important to add new line

Now we will look into more detailed explanation about all the key words in the descriptor file.

name

This is required parameter which represent the human-readable name of the module. It must be non-technical name of the module.

summary

Short description of the module.For example you can tell what business logic is implemented by this module.

version

As per the OCA guide lines for the coding standard, the version number in the module manifest should be the Odoo major version (e.g. 9.0) followed by the module x.y.z version numbers. For example: 9.0.1.0.0 is expected for the first release of an 9.0 module.

The x.y.z version numbers follow the semantics breaking.feature.fix

  • x increments when the data model or the views had significant changes. Data migration might be needed, or depending modules might be affected.
  • y increments when non-breaking new features are added. A module upgrade will probably be needed.
  • z increments when bugfixes were made. Usually a server restart is needed for the fixes to be made available.

If applicable, breaking changes are expected to include instructions or scripts to perform migration on current installations. Or you can use the more trivial system, like only specifying the version with 1.0 as base and incrementing them when we change something.

You can find out more about the OCA guide lines in here.

description

This contains an extended information about the module. This should be in reStructuredText format. Or you can use separate html file and put that in the folder path static/description/index.html, here you can put module image icon, Odoo will automatically add to the module information.

author

name of the module creator. The value must be in string format.

website

This is an optional parameter, for adding your website to the module description.

license

For every module to be published there should be a licence attached to it. As default Odoo uses opene source licence AGPL-3. In fact, the nature of the AGPL License requires all Odoo modules to be always published under the same License as the rest of the system, because they are really components of the same software. See also the License page of Odoo for more details. If you are developing for Odoo enterprise version then you can use special licence OpenERP AGPL + Private, which allows you to make a private module and not be required to give the source code to all users. Some of the common licences that Odoo uses can be seen here.

category

This is for classify the created module. There are some sample categories, which are provided by the Odoo. By default, if no category is specified Odoo will use Uncategorized. You can see all the categories by following this link. You can also create new categories by specifying the name in the __openerp__.py or __manifest__.py file. Also can create category hierarchies using the separator / for eg: Foo / Bar.

depends

This key contain a list of string which specifies all the dependent module of your module. This will ensure that Odoo will load those modules before loading your's. Adding correct dependencies to your module make the deployment more smoother.

data

It is a list of path to all the data files including xml and csv files that needed to be loaded when installing the module. List contain relative path for the data files from the module as the root directory.

demo

This is also list of data files which are only loaded when demonstration mode is activated. When you want to load some sample data, you can use this feature.

auto_install

By default this will be False. If it is True, the module will be automatically installed if all it's dependencies are installed.

maintainer

Person or entity in charge of the maintenance of this module, by default it is assumed that the author is the maintainer.

application

As default the value is False. If it is True, This represent whether the module is independent of other modules and provide new business logic to the system and considered as an application other than providing some tweaks to the existing logic.

installable

This enables the user to install the module from web ui. By default the value is False.

sequence

This represent the order of the module to be displayed. By default it is 100.

css

Specify css files with custom rules to be imported, these files should be located in static/src/css inside the module.

images

Specify image files to be used by the module.

qweb

This is for loading all your qweb templates. This is a list of all qweb template files. For importing all the qweb templates in a folder you can use the format 'qweb': ['static/src/xml/*.xml'].

test

This loads all the yaml test files. Odoo now support two type of testing methods yaml and python testing using the module unittest. In future yaml testing will be dropped and more focuses will be on python unit testing.

external_dependencies

A dictionary containing python and/or binary dependencies. For python dependencies, the python key must be defined for this dictionary and a list of python modules to be imported should be assigned to it. For binary dependencies, the bin key must be defined for this dictionary and a list of binary executable names should be assigned to it. The module won't be installed if either the python module is not installed in the host machine or the binary executable is not found within the host machine's PATH environment variable. To be in the safer side try to use try-except while importing any module, because Odoo will load the python files even if the module is not installed.

pre_init_hook

This is another optional parameter. which accepts a function name in string as an argument. Executes before installation. This will take cursor as an argument. Example of this is given below. Usually this are defined in the module __init__.py.

                            
                            
//pre_init_hook function def pre_init_function(cr) from openerp.service import common version_info = common.exp_version() print version_info.get('server_serie') return True

post_init_hook

Like pre_init_hook this is also an optional parameter. Will be called after the installation. Example of the function is defined below. Function takes cursor(cr) and registry as an arguments.

                            
                            
//post_init_hook function def post_init_function(cr, registry) from openerp.service import common version_info = common.exp_version() print version_info.get('server_serie') return True

uninstall_hook

Like above two. This function will be called after the module is uninstalled and take cursor(cr) and registry as arguments.

As for the behind the scenes of Odoo. if you look in this file. We can see that it loads all the information from each module manifest file. And when the time of database creation this information are updated in the ir.module.module table, which is part of the base module.

Hope you have got some idea about the Odoo descriptor file.