gem-hunter

Provides functionalities:

• setup empty new odoo with one bash command odoo init --version 15.0

• setup full fleged odoo server environment containing

  • supports MANIFEST file in odoo root directory to install and uninstall modules
  • postgres with pg_activity, enhanced pgcli
  • fake webmail to receive AND SEND mails
  • logs.io integration to display container output on web browser
  • dividing web, cron, queuejob container per default
  • progress bar on postgres dump/restore

• fzf compatible creation of and AST of your project

• fast restore / create snapshots of complete databases using btrfs, which helps testing things on customer databases

User-facing documentation lives in docs/ and is published at https://docusaurus.zebroo.de/docs/zodoo. Everything in that folder is published, so it should read as documentation — keep contributor and build instructions here instead.

When editing it:

• Images and other media go in docs/img/, referenced relatively: ![alt](img/foo.png).
• Page order comes from the numeric filename prefix — three digits in steps of ten (010-, 020-, 030-), never sidebar_position frontmatter, and never both. To insert a page between two others, pick a number between them: 025-new-page.md. Nothing else has to move.
• Prefixes are stripped from the published URL, so 020-getting-started.md serves /docs/zodoo/getting-started and renumbering never changes an address. It does change relative links between pages, which is why the gaps exist.
• Broken links fail the site build. A link to /docs/<section>/<page> must point at a page that is already live — not one that only exists on an unmerged branch.

• pipx
• git
• python3.13 not supported yet

bash <(curl -fsSL https://raw.githubusercontent.com/zebroo-tools/zodoo/refs/heads/main/install.sh)

cat << 'EOF' > /etc/sudoers.d/odoo
Cmnd_Alias ODOO_COMMANDS_ODOO = /usr/bin/find *, /var/lib/zodoo_env/bin/odoo *, /usr/bin/btrfs subvolume *, /usr/bin/mkdir *, /usr/bin/mv *, /usr/bin/rsync *, /usr/bin/rm *,  /usr/bin/du *, /usr/local/bin/odoo *, /usr/bin/btrfs subvol show *, /usr/sbin/gosu *
odoo ALL=NOPASSWD:SETENV: ODOO_COMMANDS_ODOO

EOF

odoo init <folder>
cd <folder>
odoo reload
odoo -f db reset
odoo up -d

# now open browser on http://localhost

• make a docker-compose file like ~/.odoo/docker-compose.yml

services:
  odoo3:
    labels:
      compose.merge: base-machine
    environment: WHAT YOU WANT
    volumes: WHAT YOU WANT

services:
  proxy:
    networks:
      network1:
        ipv4_address: 10.5.0.6
networks:
  network1:
    driver: bridge
    ipam:
      config:
        - subnet: 10.5.0.0/16

services:
    new_machine:
        ...
        labels:
          odoo_framework.apply_env: 0  # do not apply global environment from settings here

• Configure HUB_URL on the pusher side.
• >odoo login
• >odoo build
• >odoo regpush
• All images even base images like redis are pushed; tag name contains SHA name

• Configure REGISTRY=1 in settings and setup HUB_URL
• >odoo login
• >odoo regpull
• All images will be pulled from registry

• nodejs application
• between user browser and odoo
• if odoo is being restarted catches the requests, holds them and releases them to odoo if it is up again
• manages handling of /longpolling path; so if used in custom proxy setups, just refer to that one port here

odoo backup odoo-db <path> (or default name used)
odoo restore odoo-db <path> (or select from list)

The commands above dump the database to a file. For continuous backup - base backups plus WAL archive, point-in-time recovery, and a repository on a different machine - use pgBackRest. It is off until switched on (RUN_PGBACKREST), and register switches it on for you.

Setting a machine up against our backup server, in full:

odoo reload && odoo build

odoo pgbackrest register     # files a request, then stops
                             # -> an admin approves it at
                             #    https://enroll.backup.zebroo.de/
odoo pgbackrest register     # collects certificate + passphrase

odoo reload && odoo up -d
odoo pgbackrest check        # same version, certificate accepted, WAL arrives
odoo pgbackrest backup --type full
odoo pgbackrest info

Two calls with a human in between is deliberate: the passphrase cannot be replaced afterwards, so nothing is released until an admin has confirmed a second copy exists. Details, including what to do without a backup server, several projects on one machine, and recovery: docs/12-pgbackrest.md.

odoo pgactivity

The alpha branch in this repo is the staging area for unstable / experimental features that are not yet ready for main. To opt your installation in:

# in ~/.odoo/settings
ZODOO_ALPHA=1

After setting it, odoo setup upgrade switches ~/.odoo/images to the alpha branch and fast-forwards it on every upgrade (instead of jumping to the latest release tag). To leave the channel again, set ZODOO_ALPHA=0 and run odoo setup upgrade once — that puts you back on the latest semver tag.

Precedence:

1. ZODOO_DEVMODE=1 — pulls whatever branch you have checked out (wins over everything; for developers of zodoo itself)
2. ZODOO_ALPHA=1 — git checkout alpha + fast-forward pull
3. neither set — production default: check out the highest vX.Y.Z tag

Contents will be appended to [options] section of standard odoo configuration.

Configuration may simple look like:

setting1=value1

or like that:

[options]
setting1=value1

[queue_job]
settingqj=valueqj

The [options] is prepended automatically if missed.

To placed in project root.

The used odoo instance must be placed in /odoo.

{
  "server-wide-modules": ["web", "field_onchange"],
  "python_version": "3.11.10",
  "version": 17.0,
  "upgrade_path":
    [paths to upgrade src of https://github.com/odoo/upgrade-utils],
  "odoo_dir": "odoo", # default
  "install": [...],
  "uninstall": ["web_tree_many2one_clickable", "helpdesk_create_in_new_tab"],
  "devmode_uninstall": ["password_security"],
  "tests": ["helpdesk_security", "visitreports"],
  "before-odoo-update": [["update", "make-sure", "stock_delivery"]],
  "addons_paths":
    ["odoo/odoo/addons", "odoo/addons", "enterprise", "addons_tools"],
}

Put #odoo-require: crm,sale_stock in a line in your test

Put #odoo-uninstall: partner_autocomplete in a line in your test

The partner autocomplete nerves for example.

• make files like "Dockerfile.appendix" anywhere in your repo
• to add files, put a directory "Dockerfile.appendix.dir" in the same level; you can access files of it with COPY Dockerfile.appendix.dir/*

If you develop a strange external repository you can define a pre action scripts, that is executed before the reload and you can adapt some things.

EXTRA_CONFIG_your_key=value

These settings are added to the config files.

• file at /etc/odoo/after-update.sh is executed.

Best executed with:

time sudo -E pytest

• odoo debug odoo_debug inside container type: debug
• open url: http://hostname:port/debugpython
• --> container is debugged; websocket and longpolling are forwarded to odoo container
• reset cookie: http://hostname:port/debugpython_off

pipx runpip zodoo install line_profiler
$ZODOO_PYTHON -mkernprof -l -v odoo reload

When the Odoo container starts, the registry is loaded once per worker. The following parameters control how the application waits for Odoo to become ready and how it performs warmup requests to pre-fill caches.

The warmup logic:

• Waits until Odoo is reachable
• Sends a number of HTTP requests (usually to /web/login)
• Forces workers to initialize
• Warms Python caches, ORM registry, QWeb templates, etc.
• Reduces first-user latency (cold start)