Skip to main content

Odoo Doctor 🩺

Unified health scoring for Odoo custom addons.

Combines confidence-aware static analysis with optional external linters (Ruff, Pylint-Odoo) to produce a single 0–100 score per addon — designed for CI pipelines and AI coding agents.

Python 3.10+ License: MIT


Quick Start

# 1. Chạy ngay (không cần install)
pipx run odoo-doctor scan .

# 2. Install global
pip install odoo-doctor
odoo-doctor scan .

# 3. JSON output cho CI / agents
odoo-doctor scan . --json

# 4. Fail nếu score < 80
odoo-doctor scan . --min-score 80

# 5. Chỉ scan file đã thay đổi (PR review)
odoo-doctor scan . --diff main --json

What it checks

Rule Tier Category
raw-sql-string-interpolation P0 Security
missing-access-csv P0 Security
unknown-model-in-access-csv P1 Correctness
duplicate-xml-id P1 Correctness
view-field-not-in-model P1 Correctness
button-method-not-found P1 Correctness
missing-xml-ref P1 Correctness
manifest-missing-dependency P1 Module Hygiene
manifest-missing-required-fields P2 Module Hygiene
search-in-loop P1 Performance
public-controller-sudo-risk P1 Security
unbounded-search P2 Performance
manifest-data-order-risk P2 Module Hygiene
override-missing-super P1 Correctness
compute-missing-depends P2 Correctness
missing-ondelete P1 Data Integrity
data-noupdate-risk P2 Data Integrity
deprecated-api-usage P1 Upgrade Safety
removed-model-still-referenced P1 Upgrade Safety
asset-bundle-missing P2 Frontend
expensive-nonstored-compute P2 Performance
monetary-missing-currency-field P1 Correctness
missing-multicompany-rule P1 Security
unsafe-template-render P1 Security
access-write-without-group P1 Security
dynamic-method-dispatch P1 Security
rpc-sudo-without-access-check P1 Security
sql-constraints-unsupported P1 Upgrade Safety
removed-orm-api-usage P1 Upgrade Safety
cron-removed-fields P1 Upgrade Safety
view-attrs-states-removed P1 Upgrade Safety
hardcoded-company-or-currency P2 Correctness

Plus Ruff and Pylint-Odoo findings when those tools are installed.

The full, generated reference (44 rules, with before/after examples) is in docs/rules.md; every finding links to its entry. Disable a rule with odoo-doctor rules disable <rule-name>; write your own with the stable plugin API. What you can rely on across upgrades (CLI flags, exit codes, JSON keys, rule IDs) is in the stability contract. Supported Python and Odoo versions and the release support policy are in docs/support.md; scan times on Odoo 19 community are in docs/performance.md.


Score explained

Each category score starts at 100 and loses points per high-confidence finding, where each finding deducts tier_impact × category_weight (default weight 1.0; override via [category_weights]). The overall score blends only in-scope categories (those with at least one active rule):

category_score = max(0, 100 − Σ(tier_impact × category_weight))
overall        = 0.4 × min(in_scope_category_scores)
               + 0.6 × avg(in_scope_category_scores)

Tier impacts: P0 = 25, P1 = 10, P2 = 4, P3 = 1.

Label Range
Excellent 90–100
Good 75–89
Needs work 50–74
Critical 0–49

Each finding deducts points by tier: P0 = −25, P1 = −10, P2 = −4, P3 = −1.
Only high confidence findings count toward the score.

Fix first

Every scan ranks the score-eligible findings of each module by marginal score gain per effort, so you (or an agent) fix the right thing first. The terminal prints the top 5 under Fix first; --json has the top 10 per module as modules.<name>.fix_priorities:

{"rank": 1, "rule": "duplicate-xml-id", "file_path": "...", "line": 79,
 "impact": 10.0, "effort": 1, "roi": 10.0, "projected_score": 52.1,
 "score_gain": 4.7, "fixable": false}
  • effort is a coarse 1-3 estimate per rule (1 mechanical, 2 local code change, 3 restructuring); auto-fixable rules count as 1.
  • projected_score is the module score after fixing this finding and every one ranked before it; score_gain is the change this step made. A category that is already at 0 shows +0.0 until enough of its findings are fixed — the weakest category carries the 0.4 × min term, so it is ranked first.

Configuration

odoo-doctor init   # creates odoo-doctor.toml
[odoo-doctor]
odoo_version = "17.0"
addons_paths = ["."]
odoo_source_path = "/path/to/odoo/source"
capabilities = ["enterprise", "owl"]
min_score = 75

[adapters]
ruff = true
pylint_odoo = false

[severity]
"search-in-loop" = "warning"

[ignore]
rules = []
files = ["**/migrations/**"]
modules = []

[category_weights]
Security = 1.5

[surfaces.pr_comment]
min_confidence = "all"
categories = []

[surfaces.ci_failure]
min_confidence = "high"
categories = []

CI Integration

GitHub Actions

The easiest way to integrate Odoo Doctor into GitHub Actions is using our official composite action. See .github/workflows/odoo-doctor.example.yml for a full example.

- name: Odoo Doctor Scan
  uses: minhhq-a1/odoo-doctor@v0.9.1
  with:
    fail-on: warning
    min-score: 75
    diff-base: main
    pr-comment: true
    paths: "."

If you prefer pip install, you can run it directly:

- name: Odoo Doctor (pip)
  run: |
    pip install odoo-doctor
    odoo-doctor scan . --format github --min-score 75 --fail-on error

GitLab CI

ci-templates/gitlab-ci.yml defines an odoo-doctor job. Include it (pin a release tag instead of main once you depend on it) and override what you need:

include:
  - remote: "https://raw.githubusercontent.com/minhhq-a1/odoo-doctor/main/ci-templates/gitlab-ci.yml"

variables:
  ODOO_DOCTOR_ODOO_VERSION: "17.0"
  ODOO_DOCTOR_FAIL_ON: "warning"
  ODOO_DOCTOR_MIN_SCORE: "75"

Merge request pipelines scan only the files the MR changed (against the merge base, so a target branch that moved on does not leak into the scan); default-branch pipelines scan everything. The job keeps odoo-doctor-report.json as an artifact. Other variables: ODOO_DOCTOR_VERSION (pin a release), ODOO_DOCTOR_PATHS, ODOO_DOCTOR_ADVISORY=true (report only, never fail).

Bitbucket Pipelines

Copy ci-templates/bitbucket-pipelines.yml into your bitbucket-pipelines.yml (Bitbucket has no remote include). It runs on every pull request, scans only the changed files and keeps odoo-doctor-report.json as an artifact. The same ODOO_DOCTOR_* names as above are read from repository variables; the file's header lists them and shows how to also scan your main branch.

SARIF & Baseline Mode

For GitHub Code Scanning and IDE integration:

odoo-doctor scan . --format sarif > results.sarif
# Then upload via github/codeql-action/upload-sarif

To capture current debt and block only new findings in CI:

odoo-doctor scan . --write-baseline .odoo-doctor-baseline.json
# Commit the baseline, then in CI:
odoo-doctor scan . --baseline .odoo-doctor-baseline.json --fail-on warning

CI/PR Surfaces

  • --format github: Emits GitHub Actions annotations inline.
  • --score-delta <base-ref>: Opt-in PR score delta. It does a worktree-isolated second scan and needs git history (fetch-depth: 0 in Actions).
  • Sticky PR comment: Posted/updated via gh when --format github runs in a PR with a valid GH_TOKEN. Idempotent via a hidden marker. Only --format github posts it; --no-pr-comment (or pr-comment: false on the Action) turns it off.

CI failure policy

--fail-on <severity> only counts findings admitted by [surfaces.ci_failure], which defaults to P0/P1 at high confidence: style/advisory (P2/P3) and low-confidence findings are reported but never fail a build. Adjust it:

[surfaces.ci_failure]
tiers = ["P0", "P1", "P2"]   # [] = every tier
min_confidence = "high"

Score history & badge

Track the score over time and publish a badge without any server (see docs/score-history.md):

odoo-doctor scan . --history .odoo-doctor/history.jsonl --badge badge.svg
odoo-doctor history show .odoo-doctor/history.jsonl --max-drop 3   # exit 2 on regression
odoo-doctor history import history.jsonl old-report.json           # pre-0.4.0 reports

pre-commit

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: odoo-doctor
        name: Odoo Doctor
        language: system
        entry: odoo-doctor scan --diff HEAD --fail-on error
        pass_filenames: false
        types: [python]

Agent Usage

Odoo Doctor is designed for AI coding agents. Install the SKILL.md files:

odoo-doctor install   # installs to .odoo-doctor/skills/

Then in your agent workflow:

# After editing Odoo code
odoo-doctor scan . --diff main --json

# Fix P0/P1 findings with confidence: "high"
# Re-scan to verify fixes
odoo-doctor scan . --diff main --json

Use odoo-doctor rules explain <rule-name> to understand any finding (description, why, fix, examples and a docs link).

Use odoo-doctor rules stats to see which rules your team suppresses most (inline # odoo-doctor: disable, [ignore] rules, [severity] = "off"). Rules where most findings are suppressed are flagged as noisy, with a suggestion to lower their severity.

In your editor (experimental). uv tool install 'odoo-doctor[lsp]' (or pipx install; Python 3.10+) adds odoo-doctor lsp, a language server that shows the same findings as diagnostics and offers quick fixes (apply the auto-fix, or disable the rule on a line, in a file or in odoo-doctor.toml). The VS Code extension is on the Marketplace (MinhHong.odoo-doctor, preview; source in editors/vscode); setup for VS Code, Neovim and Helix is in docs/lsp.md.


Generating stubs for your Odoo version

Bundled stubs cover 17.0, 18.0, 19.0 (core models only).
For full accuracy, generate from source or a live instance:

# From Odoo source checkout
python -m odoo_doctor.graph.stubs.build_stubs source \
  --odoo-path /path/to/odoo \
  --version 17.0

# From a live Odoo instance (no source needed)
python -m odoo_doctor.graph.stubs.build_stubs rpc \
  --rpc-url http://localhost:8069 \
  --rpc-db mydb \
  --rpc-password admin \
  --version 17.0

The generated JSON is written to src/odoo_doctor/graph/stubs/data/<version>.json
(or --output <path> for a custom location).


Inline suppression

x = self.env.cr.execute(f"SELECT ...")  # odoo-doctor: disable=raw-sql-string-interpolation
<record id="my_record" model="ir.ui.view">  <!-- odoo-doctor: disable=duplicate-xml-id -->

Exit codes

Code Meaning
0 Clean — no triggered thresholds
1 Findings at or above --fail-on severity
2 One or more modules score below --min-score
3 Invalid argument, out-of-range --min-score, or git/ref failure

odoo-doctor history show --max-drop N also exits 2 when the score regressed.


Development

git clone https://github.com/minhhq-a1/odoo-doctor
cd odoo-doctor
pip install -e ".[dev]"
pytest                    # 492 test cases
pytest --cov=odoo_doctor  # with coverage

Metadata

Release files for odoo-doctor 0.9.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for odoo-doctor 0.9.1
File Size Uploaded
odoo_doctor-0.9.1.tar.gz 169.9 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for odoo-doctor 0.9.1
File Interpreter ABI Platform
odoo_doctor-0.9.1-py3-none-any.whl Python 3 none any Details

Total release size: 383.2 kB

Release files / odoo_doctor-0.9.1.tar.gz

Download URL odoo_doctor-0.9.1.tar.gz
Size 169.9 kB
Tags Source
SHA-256 checksum
How to use checksums
0a34114c938b02a5191e3e6206a34af2333d862007938493cf85524d72a725b6
BLAKE2b-256 checksum
How to use checksums
0243653bdf5ffc2ab103b571a489baf0dfe44c8079ec97890c2a1eaa2e1f8cae
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.

Transparency log

Release files / odoo_doctor-0.9.1-py3-none-any.whl

Download URL odoo_doctor-0.9.1-py3-none-any.whl
Size 213.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
1d01245e8238a8a1e6378e4efa3f1fedb31ced1215d953758e0fcc6ee0a6d1f7
BLAKE2b-256 checksum
How to use checksums
75935ec9a763d2cab261b6e683c9904f493c9bd9a283ef99028467d287a7242a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.9.1 This release

2 release files

0.9.0

2 release files

0.8.2

2 release files

0.8.1

2 release files

0.8.0

2 release files

0.7.1

2 release files

0.7.0

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page