Commit Graph
6 Commits
Author SHA1 Message Date
glenn schrooyenandClaude Opus 5 93edf9296e Use the real Odoo 19 external API (JSON-2), and batch calls
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>
2026-08-09 02:53:03 +02:00
glenn schrooyenandClaude Opus 5 3fd2c51a3d Switch the connector to JSON-RPC; drive records with buttons
JSON-RPC is the recommended Odoo API from 19 on. odoo_connect.py now posts to
/jsonrpc over stdlib urllib instead of xmlrpc.client — same x()/get_or_create()/
fields_named() surface, common.version() becomes version(), server errors raise
OdooError with Odoo's message, 600s timeout so module installs survive.

Also: state changes must go through the model's own button method, never a write
on state. Writing the field skips the delivery order, the journal entries, the
sequence and the validations a hero feature exists to demonstrate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 02:36:39 +02:00
glennandClaude Opus 5 6b48fdf126 Refuse to run on config keys the builder cannot build
build_demo.py reads every key with cfg.get(), so a config describing objects it does
not implement was skipped in silence — it printed DONE over an empty database. That
is the same "reports success over an environment that isn't" failure the purge section
exists to prevent, one layer up, and it is how a vertical config (take-offs, progress
statements) would have failed.

Unknown top-level keys now list themselves and abort. DEMO_ALLOW_UNKNOWN_KEYS=1
overrides for a deliberate partial run. Keys starting with _ stay free for comments,
so the shipped example config passes clean.

SKILL.md now states outright that build_demo.py is a per-engagement template rather
than an engine, since that is what makes the failure mode surprising.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 11:10:16 +02:00
glennandClaude Opus 5 8ea297e8bf Reseam as callista-odoo-demo: source-agnostic discovery, parallel build, follow-through
Callista consumes this pipeline for both plain Odoo implementations and
vertical demos, and is not a maintainer upstream — so the generic demo craft
that had accumulated in the buildease-demo vertical skill lands here instead,
where every engagement can reach it.

Moved in from buildease-demo (they were never construction-specific):
- Phase A: discovery brief from a transcript, notes, email, Knowcap, or a
  batched interview. Replaces the Knowcap-bound step 1. Infers before it asks.
- Fork the slow half: instance prep and client research as two parallel
  subagents, then join.
- Purge test residue: ordering, traps, read-back-the-counts evidence.
- Phase C: objection sheet, scoped quote, implementation timeline, SOW.

New here:
- Extension points — a vertical supplies module routing, solution precedence,
  purge chain, demo-data policy and follow-through framing, and nothing else.
  Anything it needs beyond those is a gap to fix here, not to work around.
- Named steps instead of numbered ones. Numbering meant an upstream renumber
  silently misrouted an extending skill with nothing to detect it.

Renamed the skill to callista-odoo-demo: skills resolve by directory name, so
a same-named fork shadows upstream depending on install order, and two people
would build different demos from the same brief.

MIT retained; SMEtools copyright kept, Callista added for modifications.
Fork point and divergence recorded in UPSTREAM.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 10:54:12 +02:00
SMEtoolsandClaude Opus 4.8 ada2751eea docs: credit Claude Code (agent) + Knowcap (memory via MCP) throughout
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SBytQq5dcASi4ETm7n6THb
2026-06-28 20:26:42 +03:00
SMEtoolsandClaude Opus 4.8 618bdcb444 odoo-demo-architect: discovery -> live Odoo demo + sales docs, AI-built
Public skill for Claude Code. Mines a discovery call, researches native-vs-custom,
stands up a working Odoo demo over XML-RPC (modules + data + tested hero features),
and generates run-of-show, one-pager, and a 1-page demo script.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SBytQq5dcASi4ETm7n6THb
2026-06-28 20:13:22 +03:00