Odoo Runner for VS Code

0.3.1 · local desktop preview · Oewer Solutions
Contact: oewersolutions@gmail.com · MIT (see LICENSE)

Manage Odoo versions, Python environments and independent runners in one dashboard. This release ports the PyCharm edition's remaining feature areas into VS Code. The two editions keep separate configuration/credentials; private Python downloads are shared.

Install and open

1. Open Extensions → … → Install from VSIX… and select artifacts/odoo-runner-0.3.1.vsix.
2. Open Odoo Runner: Open Odoo Runner in the Command Palette or use its Activity Bar/editor-title action.
3. The dashboard works in an empty window or any local folder. Restricted workspaces require trust before execution or changes.

VS Code 1.95+ is declared; native activation is checked on 1.143.1. Execution supports local macOS/Linux. Windows, Remote SSH, WSL, containers and browser-only VS Code are outside this release. Odoo and PostgreSQL are not bundled. The database tools require psycopg2 in the selected environment; restore additionally needs compatible psql/pg_restore clients. Port inspection requires lsof.

Projects, Python and runners

Add project → Odoo source → interpreter → shared standard/enterprise/custom addon directories → Save. Add runners with independent HTTP/event ports, databases, module operations and tests. New runners inherit project addon paths; each runner can override them. Module selection scans manifests without importing addon code. Drag grips and Alt+Up/Down reorder projects/runners; the sidebar divider is adjustable.

Add project → Create virtualenv detects installed interpreters. Select Python 3.10–3.14 and Install Python if needed, then enter a new absolute environment directory and Create environment. Neither operation needs Odoo source; saving/running an Odoo project does. Choose a version compatible with your checkout. Installation explicitly downloads checksum-pinned Astral uv0.13.6 and a private CPython build, with no system-Python or PATH changes. Tools/interpreters/cache stay in ~/.odoo-runner/python-tools/, shared with PyCharm and excluded from runner cleanup. macOS/Linux Intel and ARM64/glibc downloads are supported. Cancel in the progress notification; partial files can remain.

Runner cards and forms share start/restart, stop, logs, browser, Shell, database, restore and managed PID-kill actions. Icons have tooltips. Config forms group database, addon, PostgreSQL, logging, SMTP and resource settings; unknown nonsecret options remain editable. Launch & tests supports install/update module selection, a launch database override, test tags/files and development flags. Saved operations run on every launch until cleared.

Diagnostics and dependencies

Log, warnings and errors opens in the same right pane, with separate tabs, filtering, follow mode and copy for the filtered output or individual diagnostic lines. stdout/stderr and a configured logfile are read incrementally; logfile rotation and split UTF-8 are handled. The latest 1,500 diagnostic lines stay in memory. Process status is not an Odoo readiness check—inspect its output.

The project's dependency icon opens requirements-file and named-package installation with live bounded job logs, copy and cancellation. Find on PyPI looks up an exact package name/version and adds it to the draft package list. All installations require a selected virtualenv and explicit confirmation. Target/prefix environment overrides are cleared; package installation still executes trusted package code with your permissions.

Database browser and restore

The database icon lists SQL tables, partitions and views, optionally including system schemas. Search technical names/Odoo metadata; inspect estimated rows and data/TOAST/index/total sizes. Browse 100 records per page and search values in all columns or one selected column.

Edit record → Save record sends explicitly confirmed direct SQL changes. Primary/generated/protected columns, views, truncated rows and tables without a primary key are read-only. Primary keys plus PostgreSQL xmin reject stale edits. SQL editing bypasses Odoo ORM validation and computed fields. Reload after a timeout before retrying a save, since its outcome may be unknown.

Restore database accepts a trusted plain SQL or PostgreSQL custom dump, optional original filestore folder, a new database name and PostgreSQL binary directory. The workflow refuses an existing target and never drops one automatically. Use a trusted single-database dump without CREATE DATABASE/reconnect commands: SQL itself is executable input, not sandboxed. Compatible clients, psycopg2 and CREATE DATABASE permission are required. After restore, base Odoo tables are checked and the optional filestore is copied without replacing an existing directory. The runner database changes only on successful completion if selected. Progress/logs/copy/cancel stay in the right pane; failures/cancellation can leave a new partial database/filestore for inspection. Closing the dashboard cancels active restore jobs.

Embedded Shell and browser login

Odoo Shell is a real local PTY rendered inside the right pane, with interactive Python input, history and terminal resizing. It launches against the selected database using a private Shell config and excludes install/update/test launch actions. Back, project/section navigation, closing the dashboard or extension shutdown stops the Shell. Process-group cleanup is best effort; deliberately detached processes can outlive a session.

Set the instance username/password under Launch & tests → Browser login. Passwords stay in VS Code SecretStorage. The authenticated globe action logs into the running local Odoo instance, then opens a one-use loopback cookie handoff that expires after 60 seconds. Missing credentials are prompted by VS Code. Use Normal browser login / SSO for MFA/SSO or manual login. Browser cookies are host-scoped rather than port-scoped; separate browser profiles may be needed for simultaneous independent sessions.

Performance, activity and PID Killer

Performance, after Server configuration, graphs this runner's CPU/RSS including workers, plus transactions/connections for one selected database. 100% CPU means one core. Database figures cover all clients of that database; permissions may hide session state. Process samples continue while managed runners run with the dashboard closed. Database samples are visible-only. History is local, up to seven days/four 1MiB segments per runner, with at most 10,000 records loaded. Size limits can shorten retention.

Activity shows running functions, bounded action/function return history and cron/background metadata. Enable tracing, save and restart the runner. Profiling adds overhead and captures function names, locations, database attribution and inclusive wall time, not arguments or record values. A timed return does not prove success. Cron schedules alone do not prove execution; only a matching live trace is marked observed running. Unknown database attribution stays explicit. Trace history starts with a traced launch and is not an audit trail.

PID Killer inspects identifiable Odoo TCP/UDP ports and owned workers. Managed roots can be stopped; same-account Odoo port processes can be force-killed after confirmation and a fresh identity/port check. The IDE, ancestors, other accounts and unverifiable selections are protected. Discovery is permission-limited; supervisors can restart processes.

Storage, migration and credentials

Projects are global within one VS Code profile. Definitions/order are in atomic registry.json under extension global storage; per-runner config/data/history/activity/restore files are under runners/<UUID>/. Existing workspace definitions import once when that workspace is opened; original state/files remain and existing default filestore paths are preserved. Password identities remain in SecretStorage. Conflicting writes from another window are rejected; reopen the dashboard before reapplying edits. Processes belong to the window that started them and stop when that extension host exits. If a crash leaves registry.lock, close other Odoo Runner windows before removing the lock from global storage.

Settings → Import PyCharm XML accepts global odoo-runner.xml or legacy .idea/workspace.xml. IDs, source/interpreter/addon paths and runner settings are imported; existing identities are skipped. Existing default filestore locations are retained when found. Password Safe credentials cannot be read by VS Code: re-enter database/master/SMTP/instance passwords. Existing directories/databases are referenced, not copied or restored. JSON export/import remains available; exported definitions contain no passwords.

Manage storage reviews/deletes generated config, local data, saved metrics, function snapshots and temporary restore files after activity stops. Local-data deletion requires typing DELETE. Source, addons, virtualenvs, shared Python tools, external filestores and SQL databases are excluded. Removing definitions removes their SecretStorage entries but retains generated files for explicit cleanup. Generated private config contains credentials required by Odoo; review before sharing. Logs, records, Shell output and history may contain business metadata. No publisher analytics or uploads are included. See PRIVACY.md and SECURITY.md.

Build and verification

npm ci
npm run check
npm test
npm run test:webview  # Chrome; override CHROME_PATH if needed
npm run package

Optional disposable PostgreSQL integration test (all connections target a newly created temporary cluster):

ODOO_TEST_PYTHON=/path/to/test-venv/bin/python ODOO_TEST_PG_BIN=/path/to/postgresql/bin node --test test/database.integration.cjs

The test environment needs psycopg2. Backend tests cover real temporary PTY/process/tracing/PID fixtures, persistence, imports and authentication handoff. Webview tests use synthetic data and strict CSP. Database integration covers SQL/custom restore, filestore copy, stale-edit rejection and cancellation using a disposable PostgreSQL16 cluster. Native testing checks an empty VS Code window. This is not certification for every Odoo version, gevent/multiworker workload or platform. See docs/FEATURE_PARITY.md and artifacts/VERIFICATION.md in the source checkout.

TypeScript/esbuild bundles the XML parser; the terminal renderer and Python helpers are local assets. No runtime npm installation or CDN is needed. Test/build dependencies are excluded from the VSIX, and bundled licenses are supplied.

Marketplace publication has not happened. Publisher oewer-solutions is provisional; repository/support URLs and publishing setup remain owner tasks. This is independent of Odoo S.A., Microsoft and JetBrains; trademark permission is not supplied by the project's MIT license.

Runner-owned configuration files (0.3.1)

Each runner has a unique <extension global storage>/runners/<runner UUID>/odoo.conf. Add runner creates it immediately; Save, project-addon changes and successful restore synchronize it. Start refreshes it before passing that path with --config. Files use private atomic replacement, and saving one runner leaves other runners/source-tree configuration untouched. Server configuration shows the full path; opening it also creates a missing legacy file. Shell uses a separate odoo-shell.conf.

The project setup entry-script input is removed. The Odoo program is automatically detected from the source checkout, with legacy custom-launcher metadata retained only as a fallback. An odoo.conf file is configuration, not an executable. Source/Python setup, module/test arguments and per-runner server settings remain independent.

Generated configs may contain stored credentials required by Odoo before the first start, since they are now written on creation/Save. Previews stay redacted and exports exclude passwords.