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
odoo but the content will be same.
PS :This file was called
__terp__.py when Odoo was known as
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.
Now we will look into more detailed explanation about all the key words in the descriptor file.
This is required parameter which represent the human-readable name of the module. It must be non-technical name of the module.
Short description of the module.For example you can tell what business logic is implemented by this module.
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: 184.108.40.206.0 is expected for the first release of an 9.0 module.
The x.y.z version numbers follow the semantics breaking.feature.fix
xincrements when the data model or the views had significant changes. Data migration might be needed, or depending modules might be affected.
yincrements when non-breaking new features are added. A module upgrade will probably be needed.
zincrements 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.
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.
name of the module creator. The value must be in string format.
This is an optional parameter, for adding your website to the module description.
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.
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.
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.
It is a list of path to all the data files including
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.
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.
By default this will be
False. If it is
True, the module will be automatically installed if all it's dependencies are installed.
Person or entity in charge of the maintenance of this module, by default it is assumed that the author is the maintainer.
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.
This enables the user to install the module from web ui. By default the value is
This represent the order of the module to be displayed. By default it is
Specify css files with custom rules to be imported, these files should be located in
static/src/css inside the module.
Specify image files to be used by the module.
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
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.
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.
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
pre_init_hook this is also an optional parameter. Will be called after the installation. Example of the function is defined below. Function takes
registry as an arguments.
Like above two. This function will be called after the module is uninstalled and take
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
Hope you have got some idea about the Odoo descriptor file.