The manifest file is used to declare a Python package as an Odoo module and specify module metadata.

It is a file named __manifest__.py that contains a separate Python dictionary in which each key specifies module metadata.

{
    'name': "A Module".'version': '1.0'.'depends': ['base'].'author': "Author Name".'category': 'Category'.'description': """ Description text """.# data files always loaded at installation
    'data': [
        'views/mymodule_view.xml',].# data files containing optionally loaded demonstration data
    'demo': [
        'demo/demo_data.xml',]}Copy the code

The available fields are.

Name (STR, required) The readable name of the module

Version (STR) Version of the module, which should follow the version rules of semantics

Description (STR) The extended description of the module, expressed by reStructuredText.

Author (STR) The name of the module’s author

Website (STR) module author’s website URL

License (STR, Defaults: LGPL-3) License to distribute the module. Possible values.

  • GPL-2

  • Gpl-2 or any later version

  • GPL-3

  • Gpl-3 or later

  • AGPL-3

  • LGPL-3

  • Other OSI approved licenses

  • Oeel-1 (Odoo Enterprise License V1.0)

  • Opl-1 (Odoo Proprietary License V1.0)

  • Other proprietary

Category (STR, default: Uncategorized) Odoo

Although it is recommended to use existing categories, the field is free-form and unknown categories are created on the fly. Category hierarchies can be created with a delimiter /, for example Foo/Bar will create a Foo category, a Bar category as a subcategory of Foo, and set Bar as a module category.

Depends (list(STR)) The Odoo module that must be loaded before this module because it uses the functionality they create, or because it changes the resources they define.

Data (list(STR)) A list of data files that must always be installed or updated with the module. A list of paths from the module root.

Demo (list(STR)) list of data files installed or updated only in demo mode

auto_install (bool, default: False)

If it is “True”, the module will be automatically installed if all of its dependencies are already installed. It is commonly used as a “link module” to achieve collaborative integration between two independent modules.

For example, sale_CRM relies on both Sale and CRM and is set to be installed automatically. When both Sale and CRM are installed, it automatically adds CRM activity tracking to the Sale order, without sale and CRM knowing each other exists.

external_dependencies(dict(key=list(str)))

A dictionary containing Python and/or binary dependencies.

For Python dependencies, python keys must be defined for this dictionary, and a list of Python modules to import should be assigned to it.

For binary dependencies, the bin key must be defined for this dictionary, and it should be assigned a list of binary executable names.

If the Python module is not installed on the host, or if the binary executable is not found in the host’s PATH environment variable, the module will not be installed.

Application (bool, Default: False) Whether the module should be considered a mature application(True) or just a technical module (False) that provides some additional functionality to an existing application module.

CSS (list(STR)) specifies the CSS files with custom rules to import. These files should be located in static/ SRC/CSS within the module.

Images (list(STR)) specifies the image file to be used by the module.

Installable (bool default: True) Whether users should be able to install modules from the Web UI.

Maintainer (STR) The person or entity responsible for maintaining the module. By default, the author is the maintainer.

{pre_init, post_init, uninstall}_hook (STR) Hooks used for module installation/uninstallation. Their value should be a string representing the name of the function defined in the module’s __init__.py.

  • Pre_init_hook takes a cursor as its only argument. This function is executed before the module is installed.
  • Post_init_hook takes a cursor and a registry as arguments and is executed immediately after the module is installed.
  • Uninstall_hook takes a cursor and a registry. This function is executed after the module is uninstalled.

These hooks should only be used when the setup/cleanup required by the module is too difficult or impossible through the API.

Active (bool) Indicates whether the module must be installed automatically.