Writing an Odoo Manifest File Correctly

The three keys with no default

Odoo ships a default for nearly every manifest key. Three are excluded: name, author and license.

Missing author or license will not stop the install. Odoo logs a warning and carries on, falling back to contributors or maintainer for the author and to LGPL-3 for the license.

That default matters. A commercial module that forgets the key is published under an open source license by omission, and nobody is going to tell you except a log line during a load nobody was watching. Set it explicitly, always.

A manifest worth copying

{
    'name': "Sales Approval Workflow",
    'summary': "Route large sale orders through an approval step",
    'author': "CODEerts",
    'website': "https://www.codeerts.com",
    'license': "OPL-1",
    'category': "Sales",
    'version': "19.0.1.0.0",
    'depends': ['sale_management'],
    'data': [
        'security/ir.model.access.csv',
        'views/sale_order_views.xml',
        'views/menus.xml',
    ],
    'demo': ['demo/demo_orders.xml'],
    'installable': True,
    'application': False,
    'auto_install': False,
}

That is the whole set most modules need. The rest of the keys exist for specific cases rather than for completeness.

Version, and why it silently hides your module

Odoo canonicalises the version and then validates it against the running series.

The rules, from the framework itself: the version must have between two and five dot-separated parts, and if it has three or fewer parts and does not already start with the series, Odoo prefixes the series automatically. So 1.0.0 becomes 19.0.1.0.0 on an Odoo 19 server.

If validation fails, Odoo logs a warning and sets installable to False. Your module does not error, it does not appear in a broken state, it simply is not in the list. Anyone who has spent an afternoon re-checking their addons path over a version typo will recognise this.

Write the full 19.0.1.0.0 form. It removes the ambiguity and makes the target series obvious to a human reading the file.

depends is a load-order guarantee

depends is not documentation. It is what guarantees the models you extend already exist when your Python is imported, and that the views you inherit are already in the database when your XML loads.

If depends is empty, Odoo forces it to ['base'], because a module depending on nothing would load before the framework's own foundations. The one exception is base itself.

Depend on the smallest thing that gives you what you need. Extending sale orders usually means sale, not sale_management, and the difference matters to anyone installing your module on a lean database.

auto_install has three distinct meanings

This is the key most often set wrongly, because it accepts three shapes:

• False, the default. The module is opt-in and a user installs it deliberately.
• True. The module installs automatically once every module in depends is installed. This is the bridge-module pattern: a glue module between two apps that should appear only when both are present.
• A list of module names. The module auto-installs when those specific modules are installed. Odoo asserts that every name in the list is also in depends, and the install fails loudly if not, so the two lists cannot drift apart.

Use True for genuine glue. Do not use it to force your module on, which is how a customer ends up with functionality they never chose.

The keys worth knowing about

• application decides whether the module appears as a tile in Apps or only in the technical module list. It is the only technical difference between what people call an app and a module.
• external_dependencies declares Python packages or binaries you need. Declaring them means a missing dependency surfaces as a clear message at install rather than as an import traceback in production.
• assets registers JavaScript and stylesheets into bundles. Since Odoo 15 this lives in the manifest rather than in XML.
• pre_init_hook, post_init_hook and uninstall_hook name Python functions to run around installation. Useful for data setup that XML cannot express, and easy to overuse.
• sequence influences ordering in the Apps list. Default 100.
• installable defaults to True. Set it False to keep an unfinished module out of the list deliberately.

Order inside data is behaviour

The data list loads strictly in order, so it is executable rather than descriptive. Security first, then base data, then views, then menus that reference those views' actions.

A clean install that fails while an upgrade of an existing database succeeds is nearly always this: the upgrade found the referenced records already there from a previous version, and the fresh install did not. Test on an empty database before shipping, and see module structure for how the tree and the load order relate.