OCA standards, explained to developers
Thousands of modules already exist, peer-reviewed and carried from version to version. The rules that govern them evolve with Odoo: this summary says how I use them, and points to the OCA for the detail.
What is the OCA?
The Odoo Community Association publishes free modules, sorted by theme into repositories (sales, inventory, accounting…), with one branch per Odoo version. Each module is peer-reviewed before it is accepted, then carried from version to version. Its catalogue sorts them by domain; its contribution guidelines say how a module must be written, and that is where to read them, not here: they evolve with Odoo.
In short
-
Reuse before writing
Before writing a line, three questions: does Odoo already do it? Does the project already do it? Does the OCA already do it? A module that exists is a module nobody writes, and nobody maintains alone. OCA modules are taken at the project's exact version, and their code is never modified in place: a workaround lives in a module of one's own, a fix goes to the OCA if it is worth the time.
-
The conventions, as the OCA writes them
How to name a module, organise its files, write its manifest, deliver its access rights, word a commit message: the OCA's contribution guidelines say so, and automatic checks, run before every commit, verify it. I follow them as they stand: that is what lets another Odoo developer read the code without having written it.
-
Licences, read before writing
Every module has a licence, and not all of them go together: a free module under AGPL can only depend on free modules, and Odoo Enterprise's are not. The licence of each dependency is read before one's own is chosen, and a tool checks it in the repository.
-
Contribute when it helps
A module generic enough to serve others can be offered to the OCA: a branch, a single commit, a merge request reviewed by peers. I do not promise that everything goes upstream: when a local fix is enough, it stays local. My contributions are public.
Before writing a line
Three questions, in order, then we write.
-
Does Odoo already do it?
Often, in a corner of the configuration, or in a standard module not yet installed.
-
Does the project already do it?
An existing module, to extend by inheritance rather than duplicate.
-
Does the OCA already do it?
The catalogue, then a search through the repositories of the target version.
-
Then we write
The OCA way, so that it can go back there.
To go further
The OCA pages that prevail, to read before any contribution:
- The contribution guidelines: module structure, Python, XML, tests, commits, review.
- The module catalogue, by domain and version.
- How to contribute: the contributor agreement, the review cycle, the repositories.
- OpenUpgrade: database migration from version to version.
What it costs
Reading before writing, and accepting that an existing module covers 80% of the need. Checks that refuse a commit. A proposal to the OCA that waits weeks for review. That is the price of code that outlives its author.
Do you do it differently?
A disagreement, a better way, a case that does not fit these rules: write to me, I read everything.
The other methodologies
-
Modular development, explained to developers
The rules, an example in three modules and two code samples, for whoever starts out with Odoo.
-
Automated tests, explained to developers
The rules, a bug taken in four steps and a ten-line test, for whoever starts out with Odoo.