Odoo

Odoo

Overview

Use this skill to work on Odoo code without guessing the framework version. Odoo behavior changes across major and minor releases, so determine the installed version and local addon conventions before applying docs, snippets, or migrations.

First Step: Identify Version

Before editing or explaining Odoo code, identify the target version:

python skills/odoo/scripts/inspect_odoo.py --root <repo-or-addon-path>
python skills/odoo/scripts/inspect_odoo.py --root <repo-or-addon-path> --json

If the script cannot determine the version, inspect in this order:

1. odoo/release.py, odoo/tools/config.py, odoo-bin --version, or setup.py.
2. Docker image tags, CI files, requirements.txt, pyproject.toml, and deployment scripts.
3. Addon manifests in __manifest__.py or older __openerp__.py.
4. Local code conventions: imports, decorators, asset bundle syntax, JS module format, and test style.

Do not cite or copy examples from a different Odoo version unless the local source confirms compatibility.

Workflows

For every task, read the relevant local addon files first:

• __manifest__.py or __openerp__.py
• models/, views/, security/, data/, demo/, controllers/, reports/, static/, tests/, migrations/
• dependency addons declared in the manifest
• inherited models and views referenced by _inherit, inherit_id, ref, xml_id, and XPath expressions

Then follow the task-specific checklist:

• ORM/model work: verify _name vs _inherit, field definitions, compute/inverse/search, store=True, depends, constraints, SQL constraints, access rights, record rules, multi-company behavior, and prefetch/cache implications.
• Views/XML: verify target view exists in the same version, XPath still matches, external IDs resolve, groups/context/domain are valid, and inherited view priority is intentional.
• Security: inspect security/ir.model.access.csv, ir.rule, groups, implied groups, field-level groups, and portal/public controller exposure.
• Controllers/API: verify route auth, CSRF, sudo usage, request env user, public access, and input validation.
• Reports/QWeb: inspect report action, template XML IDs, paper format, language/company context, and assets.
• JS/assets: treat module format, Owl APIs, registries, services, and asset declarations as version-specific.
• PostgreSQL/debug data: read references/postgresql-debug.md; inspect database state read-only first and map findings back to ORM, rules, context, cache, and module metadata before proposing direct DB changes.
• Tests: prefer the repo's existing Odoo test command and tags. If absent, read references/workflows.md.
• Migration/upgrade: compare source and target versions explicitly; never assume a migration pattern is cross-version.

Version-Specific References

• Read references/versioning.md when version, docs URL, or source compatibility matters.
• Read references/workflows.md for module inspection, test commands, security checks, and performance checks.
• Read references/postgresql-debug.md when the task involves psql, Odoo database state, slow SQL, failed upgrades, XML IDs, views in DB, module state, record rules, or direct data repair.

When the exact current Odoo docs, CLI syntax, or API changed recently, browse the official versioned Odoo documentation before answering.

Output Rules

• State the detected Odoo version or say it is unknown.
• Name the addon/module boundaries touched.
• Include the exact test command used or explain why tests were not run.
• For database debugging, state whether queries were read-only and whether direct DB writes were avoided.
• For uncertain version compatibility, say what local evidence supports the choice.