- What is obuchmann/odoo-jsonrpc used for?
- It is a PHP connector that communicates with Odoo ERP over Odoo's JSON-RPC API, packaged for Laravel integration. It provides a fluent, Eloquent-like model interface so you can authenticate and then query, create, update, and delete Odoo records from normal Laravel application code. It acts as an adapter layer between your Laravel app and Odoo as the ERP system of record, which is preferable to hand-rolling raw RPC calls.
- How do I install obuchmann/odoo-jsonrpc in a Laravel application?
- Install it with Composer, which registers the service provider through Laravel package discovery, then publish the package config file. Credentials for host, database, and user go in the published config or in your env file. Pin the constraint to ^1.9 rather than floating to any version, since this is a single-maintainer dependency.
- Which Laravel and PHP versions does this package support?
- The package follows standard Laravel package conventions with service-provider and config-publish registration, and it is used on Laravel 8 through 11 with PHP 8.x. The more important compatibility axis is the Odoo side rather than the Laravel side, so verify behavior against the specific Odoo major version you run. Re-test after Odoo upgrades independently of any package version bump.
- How do I configure the Odoo connection credentials?
- After publishing the config file, set the Odoo host, database name, and username, plus the password or API key used for authentication. These values are typically supplied through environment variables rather than committed to the config file. Authentication and JSON-RPC session handling are managed by the connector, but you should still confirm session lifecycle behavior in long-running or queue-based workers.
- How do I query, create, update, and delete Odoo records with this package?
- You work through the package's Eloquent-like model classes instead of writing raw JSON-RPC payloads yourself. Reads and searches return hydrated models, and writes are serialized back into Odoo's expected payload format through a dehydration pipeline that also handles nested relations. Create, update, and delete operations all flow through that same write-back path, which is where protocol-shape bugs tend to appear.
- Why do relational field writes fail with Odoo validation errors?
- Odoo's x2many protocol requires exact tuple encodings, for example (0, 0, values) to create and (6, 0, [ids]) to replace a set, while many2one fields expect a scalar ID rather than an array. A mismatch is rejected by Odoo's ORM rather than by PHP's type system, so unit tests with mocked responses will not catch it. These faults typically surface in staging or production as opaque validation errors, which is why round-trip testing against a real instance matters.
- What changed in version 1.9.1 of obuchmann/odoo-jsonrpc?
- It is a single-commit patch release that fixes the dehydration pipeline, the write-back path that serializes a hydrated model graph into Odoo's expected payload. Foreign-key fields arriving as arrays were producing payloads Odoo rejected, and the fix normalizes that shape before submission. There are no signaled API changes, deprecations, or config changes, but you should confirm whether the fix covers both the create and update paths and both one2many and many2many relations.
- How should I test the Odoo integration safely before production?
- Build a minimal reproduction against a non-production Odoo database: a model with a foreign-key field populated as an array, written back through dehydration. Confirm the fix resolves the failure and that ordinary scalar-ID foreign-key writes still behave correctly. Then run your full staging sync and round-trip suite, because mocked JSON-RPC responses cannot validate payload shape against Odoo's ORM.
- Does this package provide transactions spanning Laravel and Odoo?
- No. There is no transaction that spans your Laravel database and Odoo, so a write can succeed on one side and fail on the other. Design for idempotent operations and compensating logic rather than assuming atomicity. Wrapping package calls behind an internal repository or gateway interface also limits the blast radius if you later swap the connector.
- Which Odoo versions are supported, and what should I watch for in maintenance?
- The real compatibility question is your Odoo major version, since Odoo version drift across majors changes protocol expectations, so validate against the instance you actually run. The project is small, single-maintainer, GitHub-hosted, and community-supported with no SLA or vendor escalation path. Treat it as a watch-list dependency: budget time to read each diff, because changelog entries are terse and patch releases here can encode non-obvious behavioral corrections. Alternatives include hand-rolling JSON-RPC calls or using another connector, both of which shift the protocol-encoding risk onto your team.