mcpField
O
odoo-best-practices

odoo-best-practices

github.com/mercatorprojDevelopment160 installsUpdated 2w ago
Repository

About odoo-best-practices

odoo-best-practices is a guidance skill for building, extending, and reviewing Odoo modules for versions 18–20. It emphasizes ORM-based development, safe extensions, security, and focused references for specific tasks.

Key features

  1. 01Odoo 18–20 module guidance
  2. 02Favor extensions over core modifications
  3. 03ORM and access-control practices
  4. 04Routing to topic-specific references
  5. 05Guidance for testing and performance

Use cases

  1. 01Design a custom Odoo module
  2. 02Review model and access-rule implementations
  3. 03Build or inherit XML views and OWL components
  4. 04Prepare tests or optimize ORM queries

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mercatorproj/odoo-best-practices --skill odoo-best-practices

After installing, type/odoo-best-practicesin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

LICENSE
README.md
agents/
openai.yaml
references/
official-docs.md
frontend-architecture.md
module-architecture.md
dev-environment.md
project-roadmap.md
external-api.md
orm-patterns.md
testing-performance.md
testing.md
security-i18n.md
views-owl.md

Details

From the project README

Odoo Best Practices

Apply these practices when building, extending, or reviewing Odoo modules targeting versions 18-20. The guidance assumes Odoo 20.0 conventions unless the user specifies an older version.

Design Philosophy

These rules exist to uphold Odoo's core design philosophy:

  1. Everything is a module — even Enterprise features are just modules stacked on top of Community.
  2. Data is the program — views, actions, menus, and security rules are database records; XML data files install them.
  3. Extend, never modify — model _inherit, xpath view inheritance, QWeb inheritance; a pristine core upgrades cleanly.
  4. XML IDs are the glue — module.xml_id is the global namespace; depends behaves like a system package manager.
  5. Convention over configuration — names map automatically to tables, columns, and UI; follow the naming conventions.
  6. The ORM is the API and the security boundary — public methods are RPC-exposed; raw SQL bypasses security.
  7. Integrated by design — one database, shared base models; OWL is the presentation-tier direction.

When in doubt, choose the option that keeps future upgrades safe and stays within the ORM.

Core Rules

  • Never modify core modules. Always extend via _inherit in a custom module.
  • Every new model must define _description and have access rules in ir.model.access.csv.
  • Use api.onchange for UI-only validation and api.constrains for database-level invariants.
  • Prefix custom module names with a vendor or project namespace (e.g., mycompany_feature) to avoid collisions.
  • Set version in __manifest__.py to match the Odoo series (e.g., 20.0.1.0.0).
  • Mark user-facing strings with _() for translation support.
  • Use recordset methods (mapped, filtered, sorted) over Python loops when possible to leverage ORM prefetch.
  • Prefer sudo() sparingly; always document why elevated access is needed.
  • Never concatenate domains from user input; use the Domain object (domain &= Domain(...)) to prevent injection.
  • Use models.Constraint / models.Index (Odoo 20+) instead of legacy _sql_constraints.

Routing

Read the relevant reference when the task touches that area. Do not load all references by default.

Comments

Markdown supported