Skip to content

Developer Guide

This section is for engineers — whether you contribute upstream to roots_hemms_*, build a customer-specific extension on top of HEMMS, or operate a HEMMS deployment and need to know how the moving parts fit together.

Start here

  • Architecture

    The three-layer composition (Odoo base → OCA → roots_hemms_*), the field-naming convention, and the OCA-vs-roots_hemms_* decision matrix.

    Read Architecture

  • Module Development

    Scaffold a new roots_hemms_* module, depend on the right HEMMS layer, write tests in the project pattern, and wire it into CI.

    Read Module Development

  • API Reference

    Per-module model + field reference. Useful when you want to _inherit a HEMMS model, hook a compute, or extend a report.

    Browse the API

  • CI / CD

    GitHub Actions workflows that gate every PR — lint, 177 tests, docs build. How to reproduce CI locally with make ci.

    Read CI/CD

  • Contributing

    Docs / commit / PR workflow. Style conventions for Markdown, admonitions, code fences, and screenshots.

    Read Contributing

  • Session 1 Build Notes

    Design decisions from the original build session. Why things are the way they are — useful when something looks "weird" and you want the rationale.

    Read Build Notes

Quarter design plans

Each shipped quarter has a frozen design plan committed alongside the code. Read these before opening a PR that touches that quarter — the plan documents the decisions (and the rejected alternatives) that shaped the implementation.

Q1 (foundations) and Q7 (CI/CD) didn't ship with explicit qN-*-plan.md files — their context is captured in Session 1 Build Notes and CI/CD respectively.

Audience guide

You are... Start here
A new contributor wanting to ship a small fix Contributing → CI/CD → open a PR
A new contributor wanting to ship a new module Architecture → Module Development → a relevant Q-plan as a worked example
A hospital integrator wiring HEMMS into a third-party system API Reference → the relevant module's user docs under modules/
An auditor verifying compliance logic Architecture and the Compliance section — every Layer-3 module maps to a single compliance concern by design

House rules

  • Follow the 3-layer rule. Your custom code goes in Layer 3 (addons/roots/), not in Layer 2 (addons/oca/) or Layer 1 (Odoo base). Architecture explains why.
  • Follow the field-naming convention. Hospital-specific fields on inherited models use the roots_ prefix. Brand-new models defined in HEMMS use a hemms. _name prefix; their own fields don't need redundant prefixing.
  • CI must stay green. Lint + 177 tests. Reproduce locally with make ci before pushing. If CI catches a real bug the first time it runs (it has, three times now — see Release Notes), fix the bug, don't disable the test.
  • Pre-commit is mandatory. ruff, pylint_odoo, and oca-checks-odoo-module run on every commit. Install with pre-commit install after cloning.

Have fun. Read Roadmap for what's queued next and where the open spots for community contribution are.