Skills
Odoo development means extending an ERP without breaking the consistency of its business model, permissions, and internal mechanisms. A module can add Python models, fields, XML views, QWeb reports, scheduled actions, API controllers, configuration data, and migration scripts. The difficulty is not merely making each component work: the ORM, inheritance, execution context, module dependencies, and framework conventions must be understood so a customization remains installable, testable, and compatible with future releases.
The skill also includes translating requirements. In an ERP, a technical rule often represents an accounting, sales, logistics, or security decision. I must identify reliable data, authorized users, exceptions, and effects on other applications. ACLs grant operations at model level, record rules restrict accessible records, and groups compose a user's privileges; hiding a screen is therefore never sufficient protection.
Finally, developing for Odoo requires choosing between standard behavior, configuration, Studio, and a version-controlled module. I favor standard functionality when it addresses the need, configuration when the rule should remain controlled by users, and code when behavior requires durable, reviewable, deployable logic. This boundary reduces technical debt and simplifies migrations.
The Odoo 19 release notes document cross-cutting changes to activities, customer documents, interfaces, and business applications. For an Odoo developer, each new release means understanding native capabilities before adapting existing modules and customizations.
Read the source: OdooI owned the successive migration from Odoo 16 to 17, 18, and then 19 for an ERP used by 20 internal users and around ten sales agents. The project included 16 custom modules, around ten third-party extensions, and several hundred Studio customizations. At each step, I adapted incompatible models, Python methods, XML views, and XPath expressions, researched changes in the source code, retrieved or fixed third-party modules, and checked PostgreSQL data and the filestore. Acceptance testing covered business processes, permissions, and external integrations, with a complete backup as the rollback point.
Result — Odoo 19 was deployed to production with no permanent data loss and downtime limited to roughly three hours. Useful functions were retained, most obsolete Studio customizations were removed, and the main integrations were modernized.
I developed and maintained sixteen modules that extend the ERP for accounting, sales, inventory, logistics, and sales administration. The overdue-reminder module illustrates the complete approach: requirement gathering, decision matrix, settings, Python models, XML views, permissions, scheduled action, email templates, attached report, staging tests, business validation, Odoo.sh deployment, and training. Other modules enrich products, QWeb reports, invoice margins, or logistics documents. I select only the directories and components required by the need instead of mechanically reproducing a full structure.
Result — These modules automate daily tasks, make documents more complete, and provide management indicators during the financial year. The reminder module alone saves around half a working day each week.
The B2B website and integration hub depend on customers, products, stock, and orders stored in Odoo. I created focused API routes when standard mechanisms did not satisfy the exchange contract and helped adapt integrations to Odoo 19's JSON-2 API. To prevent an interface solution from exposing data, I reason separately about ACLs, groups, record rules, and sensitive fields. When behavior appears inconsistent, I read logs, trace method inheritance, and inspect source code rather than accumulating workarounds in views.
Result — External systems recovered their main exchanges after the migration, and internal modules remain controlled in the versioned repository. This ability to work down into the framework lets me correct a defect's cause rather than only its display.
I assess myself as advanced. I can design, migrate, secure, deploy, and maintain modules spanning several departments, and I can investigate behavior in the source code. I do not consider myself an expert: the accounting engine, deep ORM optimization, and some internal interactions remain areas where I need more measurement before making changes.
This is the most important technical skill in my current profile. It combines Python, PostgreSQL, XML, APIs, security, deployment, and understanding of business processes. It also matches my objective of becoming a senior developer and Odoo technical reference.
I learned Odoo from scratch during work-study while quickly becoming the only in-house developer responsible for requests. Modules, incidents, and migrations accelerated my progress beyond a purely theoretical path, but that speed also explains some early implementations that relied too heavily on fixed values.
My advice is to start with the business process and standard features before writing a module. Configuration and algorithm should then be separated, tests run with representative accounts and data, and source code inspected as soon as actual behavior contradicts the hypothesis. Studio is useful for a lightweight change, but version-controlled code is preferable when logic is critical or durable.
Consolidate an advanced level until I can define the architecture of a module suite, prepare migrations in advance, and guide other developers on security, performance, and maintainability decisions.
I continue reading source code and official documentation, studying migration scripts, and automating Odoo tests. My next practical areas are margin-calculation performance, JSON-2 integrations, and the future Business Intelligence architecture connected to the ERP.