ODEV Commands Skill

This skill provides instructions on how to use odev (Odoo Development CLI) during upgrade tasks.

🛑 MANDATORY RULES (ODEV CLI USAGE)

1. VERSIONING: You MUST specify the Odoo version explicitly using the -V <version> flag when creating a

database (odev create). For other commands like odev run, odev shell, or odev test, the -V flag is optional if the database already exists, as odev will automatically infer the version from the database. However, if you are targeting a specific version that differs from the database or if the database does not exist, specifying -V is required.

- Example: odev run -V 19.0 ...

1. ARGUMENT ORDER: odev specific flags (LIKE -V, -f, -c, -w, --venv) MUST come BEFORE the database name.

1. DATABASE CREATION/OVERWRITE: You MUST ALWAYS use the -f (force) flag when creating a database that might

already exist to bypass confirmation prompts. "Overwriting" an existing database via odev create REQUIRES -f.

- Example: odev create -f -V 18.0 new_db -i base

1. LOG LEVEL: Use --log-level=warn to keep logs concise and save tokens. Note that odev consumes this flag to

set BOTH its own log level and the Odoo server log level.

1. GLOB QUOTING: When using --glob, you MUST ALWAYS wrap the pattern in double quotes to prevent the shell from

expanding it before it reaches odev. - Incorrect: odev upgrade-code --glob my_module/**/* - MANDATORY: You MUST always include --stop-after-init when using odev run or odev deploy for verification. Failure to do so will cause the shell to hang.

1. ADDONS PATHS: odev automatically manages Odoo and Enterprise addons paths based on the specified version

(-V). You should NEVER manually specify standard Odoo paths (like odoo/addons or enterprise). odev handles this internally. Additionally, odev automatically includes the repository path of the targeted database. If you are working in a custom folder, odev will often include it if it's detected as an addons path. Trust odev for the plumbing to avoid version mismatches.

Core Commands

• odev run <database> [options]:

- Starts the Odoo server. - Useful for manual verification and testing. - DATABASE EXISTENCE: The database MUST exist. If it does not, an error will be thrown. - VERSIONING: If -V <version> is omitted, odev takes the version from the database. - MANDATORY: Always specify --stop-after-init when running in a script or for automated verification. - Best Practice: Always specify --http-port <free_port> to avoid conflicts. - Example: odev run db -i mod --http-port 8069 --log-level=warn --stop-after-init

• odev create -V <version> <database> [options]:

- Creates a new database and installs modules. - MANDATORY: You MUST always specify the Odoo version with -V <version> when creating a new database. - MANDATORY: Use -f to force creation if the DB already exists. - Use -T to create a template database (e.g., odev create -f -T -V 17.0 mytemplate -i sale). - Use -t <template> to clone from a template (e.g., odev create -f -t mytemplate -V 17.0 new_db).

• odev test <database> -i <modules> [options]:

- SURGICAL VERIFICATION: You are ENCOURAGED to use this command to verify individual fixes, but ONLY with specific tags to keep it fast. - MANDATORY: You MUST use -t <tag> or --tags <tag> to run ONLY the relevant failing test. - Example: odev test mydb -i mymodule -t .testsomemethod - Avoid Full Suites: DO NOT run odev test without specific tags. Full module tests take too long and consume too many tokens. The host framework will run the full suite automatically after your session.

• odev venv <database> -c "<command>":

- Runs a command inside the virtual environment associated with the database. - Package Installation: If a python package is missing, use: odev venv <database> -c "pip install <package>".

• odev shell <database> [options]:

- Starts an interactive Odoo shell for the specified database. - Use --script "<pythoncode>" to execute code and exit immediately. - Example: odev shell mydb --script "print(self.env.user.name)"

• odev deploy <module_path> [options]:

- Hot-deploys a module to a running Odoo instance. - Example: odev deploy /custom/my_module

• odev kill -H <database> [options]:

- Kills the running Odoo process associated with a database. - Use -H (hard) to send a SIGKILL if the process is stuck. - Example: odev kill my_db

• odev delete -f <database> [options]:

- Deletes an existing database and its associated resources (filestore, config). - MANDATORY: Use -f (force) to bypass confirmation prompts. - Prerequisite: If the database is currently running, you MUST kill it first using odev kill <database>. - Example: odev delete -f my_db

• odev upgrade-code <database> --from <ver> --to <ver>:

- Automatically migrates source code for common renames (e.g., <tree> to <list> in Odoo 18.0+). - MANDATORY: You MUST specify the target database name, not a directory path.

Best Practices

• Speed up iteration: Use template databases (-T and -t) to avoid reinstalling standard Odoo modules

repeatedly.

• Strict Versioning: Pass the -V flag when creating a database. For other commands, only use it if you need

to target a specific version that differs from the database default.

• Prompt Bypassing: Always use -f in scripts or automated tasks to ensure no interactive prompts block

execution.

📦 MODULE MANIFEST STANDARDS

1. VERSIONING: When upgrading a module to a new Odoo version, you MUST reset the version in manifest.py to

ODOOVERSION.1.0.0 (e.g., 19.0.1.0.0). - NEVER preserve minor versions or patch increments from the source Odoo version (e.g., do not turn 16.3.1.2.3 into 19.3.1.2.3). - The format MUST be: <odoomajor>.0.1.0.0 for the first upgrade commit.