glenn schrooyenandClaude Opus 5
93edf9296e
The previous commit moved to /jsonrpc, which the v19 docs list as deprecated
alongside /xmlrpc — both go away in Odoo 22. The actual v19 external API is
JSON-2: POST /json/2/<model>/<method>, API key as a bearer token.
Three consequences, all of which change calling code:
- no uid and no password; UID now comes from res.users/context_get
- every argument is named, positional args do not exist, so x() becomes
x(model, method, ids=None, **kwargs) and callers pass domain=/vals=/fields=
- one call is one transaction and nothing chains, which is the mechanical
reason state changes must go through a button method
Batching: no multi-call envelope exists, so batching means widening a call, not
bundling calls. Added get_or_create_many() (one search_read + one create for a
whole set) and put build_demo.py's product, customer, vehicle, invoice and
headroom loops through set-based calls.
test_odoo_connect.py checks the call shape and the batching offline, with a
faked urlopen — none of this can be exercised without a live instance otherwise.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
83 lines
4.4 KiB
Markdown
83 lines
4.4 KiB
Markdown
# Callista Odoo Demo
|
||
|
||
**Turn a discovery call into a complete, working Odoo demo — and the documents to sell it, before and after the meeting — with an AI agent doing the build.**
|
||
|
||
> Fork of **[Smetools/odoo-demo-architect](https://github.com/Smetools/odoo-demo-architect)** (MIT). See [`UPSTREAM.md`](UPSTREAM.md) for the fork point and what diverges.
|
||
|
||
A Claude Code skill. Point it at whatever discovery material exists — a transcript, meeting notes, an email thread, Knowcap, or nothing at all — and a reachable Odoo instance. It writes the discovery brief, researches what Odoo does natively vs. what needs building, stands up a **live database** (modules + realistic data + the 1–2 "hero" features that win the deal), **tests** that those features actually fire, and generates the sales documents. After the demo it writes the follow-through set.
|
||
|
||
## Three phases
|
||
|
||
| Phase | Produces |
|
||
|---|---|
|
||
| **A — Discovery brief** | `discovery_brief.md` in a fixed six-section shape, from any source. Infers first, asks the gaps in one batch |
|
||
| **B — Build** | A live Odoo DB with working heroes, a verification log with real numbers, and three sales docs: run-of-show, decision-maker one-pager, 1-page demo script |
|
||
| **C — Follow-through** | Objection sheet, scoped quote, implementation timeline, statement of work |
|
||
|
||
Each phase is usable alone. Phase C runs days after the demo.
|
||
|
||
## Verticals extend this
|
||
|
||
Vertical skills (e.g. `buildease-demo` for construction) wrap this one and supply only
|
||
their own module routing, solution precedence, purge chain, demo-data policy, and
|
||
follow-through framing. They do not restate the pipeline. See
|
||
[Extension points](SKILL.md#extension-points).
|
||
|
||
## Install
|
||
|
||
```bash
|
||
git clone <this repo> ~/.claude/skills/callista-odoo-demo
|
||
```
|
||
|
||
Then ask Claude: *"build an Odoo demo for <client> from these notes."*
|
||
|
||
**Do not** install this as `odoo-demo-architect` — skills resolve by directory name, and a
|
||
same-named fork silently shadows upstream depending on install order.
|
||
|
||
## Prerequisites
|
||
|
||
- **Claude Code.**
|
||
- A reachable **Odoo instance + API key** (Settings → My Profile → Account Security → New API Key).
|
||
- On **Odoo.sh**: create the project + enter any partner trial code first (web-only), then come back with the DB URL + API key.
|
||
- Optional: **Knowcap** with its MCP connected, as one possible discovery source → [knowcap.ai](https://knowcap.ai).
|
||
- Optional: the **Perplexity MCP** for the native-vs-custom research step (web search works too).
|
||
|
||
## Quickstart
|
||
|
||
1. Put your Odoo creds in env vars (or `scripts/creds.json`): `ODOO_URL`, `ODOO_KEY`, and
|
||
`ODOO_DB` if one domain serves several databases. JSON-2 authenticates on the API key
|
||
alone — there is no login/password, so no `ODOO_LOGIN`.
|
||
2. Verify the connection: `python scripts/odoo_connect.py` → prints the server version and uid.
|
||
(`python scripts/test_odoo_connect.py` checks the call shape offline, no server needed.)
|
||
3. Copy `demo_config.example.json` → `scripts/demo_config.json`, fill it from the brief.
|
||
4. Ask Claude to run the pipeline (see [`SKILL.md`](SKILL.md)).
|
||
|
||
`scripts/creds.json` and `scripts/demo_config.json` are gitignored — they hold client API keys. Keep it that way.
|
||
|
||
## Read this before touching Odoo 19
|
||
|
||
Several core fields were renamed in v19 (`res.users.group_ids`, `res.groups` lost `category_id`, etc.), credit limit is **warning-only** natively, and fleet load-by-weight needs `stock_fleet`. All the footguns are in [`reference/odoo19-field-gotchas.md`](reference/odoo19-field-gotchas.md) so you don't relearn them the hard way.
|
||
|
||
## Files
|
||
|
||
```
|
||
SKILL.md the procedure (what the agent follows)
|
||
UPSTREAM.md fork point + divergence from upstream
|
||
scripts/odoo_connect.py JSON-2 connector + helpers
|
||
scripts/build_demo.py config-driven data + hero builder (template)
|
||
scripts/test_odoo_connect.py offline self-check of the JSON-2 call shape
|
||
demo_config.example.json per-client config shape
|
||
reference/odoo19-field-gotchas.md version-specific fields + footguns
|
||
templates/ brand.css + the doc templates
|
||
```
|
||
|
||
## License
|
||
|
||
MIT — see [`LICENSE`](LICENSE). Original copyright SMEtools; modifications Callista BV.
|
||
|
||
## Credit
|
||
|
||
Original by **[SMEtools](https://www.smetools.io)** — Odoo implementation + AI automation.
|
||
Fork maintained by **[Callista BV](https://www.callista.be)**.
|
||
Runs on **[Claude Code](https://claude.com/claude-code)**.
|