@soltein-net/solt-odoo-rpc

Generic, domain-agnostic Odoo XML-RPC client, authentication, and typed errors.

Zero knowledge of any specific Odoo domain (helpdesk, project, ...) and zero MCP dependency — enforced by this repo's own CI (boundary-check.yml). Consumed today by solt-helpdesk-mcp's core-lib, and, later, by other domain-specific packages (e.g. a future solt-project-mcp), but never depends on any of them.

See soltein/docs/approved/ide-helpdesk/SPEC.md (§2.2, §2.9) for the full architecture this package is part of. See CONTRIBUTING.md for local development.

Installing (as a consumer)

This package is published to GitHub Packages, not the public npm registry, so installing it needs one extra step beyond a normal npm install: a GitHub personal access token with read:packages scope, and a registry mapping for the @soltein-net scope.

Add to the consuming repo's .npmrc (already present in core-lib/mcp-server):

@soltein-net:registry=https://npm.pkg.github.com

Then authenticate once, locally:

npm login --scope=@soltein-net --registry=https://npm.pkg.github.com
# username: your GitHub username
# password: a GitHub PAT with read:packages scope

In CI, set NODE_AUTH_TOKEN to a token with read:packages (GitHub Actions' own secrets.GITHUB_TOKEN already has this when installing from within the same org's workflows).

API

import { authenticate, executeKw } from "@soltein-net/solt-odoo-rpc";

const config = { url: "https://your-odoo-instance", db: "your_db", login: "[email protected]", apiKey: "..." };
const uid = await authenticate(config);
const [record] = await executeKw(config, "res.users", "read", [[uid], ["id", "login"]]);

Typed errors (OdooAuthError, OdooNetworkError, OdooValidationError, OdooAccessError, and the common base OdooRpcError) are exported from the same package — see src/errors.ts.

Depending on this from a future domain server (e.g. solt-project-mcp)

Add it as a normal dependencies entry ("@soltein-net/solt-odoo-rpc": "^0.1.0"), with the .npmrc/auth setup above. This package has no opinion about what model/domain you call executeKw against — that's entirely up to the domain-specific core-lib you build on top of it, same as solt-helpdesk-mcp's own core-lib does today.