A French Odoo 11 platform for Wood, a pool-equipment supplier — built around a metadata-driven product configurator that lets customers spec a pool through a dynamic questionnaire whose entire shape is rows in the database.
Wood is a French pool-equipment supplier. Their Odoo 11 platform runs the catalogue and the order pipeline — and at its heart, a metadata-driven product configurator that lets customers spec their pool through a dynamic questionnaire whose entire shape is rows in the database.
The configurator is the interesting part. `product.abstract` is the top-level template; `config.block`, `config.fieldset`, `config.question` and `config.question.value` describe the form's shape; `config.condition.*` rows hold the visibility and validation rules as strings, evaluated at runtime; `config.controller` rows wire questions together; `config.global.value` rows hold form-level computed values. `product.abstract.extract()` serialises the whole tree into JSON; a jQuery widget reconstructs the form on the frontend; `sale.order.create_from_vals()` reads it back.
The arrangement gives Wood a configurator they can grow without us — new questions, new conditions, new computed values, all admin-side. It also concentrates business logic in `eval()`-evaluated strings, which is the part that strains as the form expands. We've documented an eight-phase plan in `docs/configurator.md` to move from DB-metadata-driven to code-driven configuration; the plan is there for when the work is ready.
We've been on the platform since 2021. The cadence is light — a handful of commits a year, mostly configurator extensions, occasional invoicing and stock module work, the Dropbox backup integration. Odoo 11 is well past mainstream support; Wood's choice to stay on it is deliberate, and our job is to keep the platform stable on a version the rest of the world has moved past.
Core: the configurator data model, quote / order logic, pricing through composition formulas.
Shared base extensions used by every nembia_* addon.
Invoice customisations with French localisation.
Stock management with SMS notifications for stock events.
After-sales service: tickets, follow-up, history.
Web controller extensions backing the public-facing pages.
Dropbox-backed nightly backups (credentials gitignored).
`product.abstract.extract()` serialises the form tree; the jQuery widget reconstructs the UI; `sale.order.create_from_vals()` reads the answers back.
Eight-phase migration plan from metadata-driven to code-driven configuration — written when we hit the architecture's ceiling, kept in the repo for the day it becomes the work.
The customer's pool-spec questionnaire is rows in the database, not lines in code. New questions, new visibility conditions, new computed values — all admin-side. We pay for that flexibility with `eval()`-evaluated condition strings; we earn it with a configurator Wood can grow without us.
Wood runs on Odoo 11, well past mainstream support. The client's choice to stay there is deliberate — the configurator and the business logic that's built around it. Our job is to keep the platform stable on a version the rest of the world has moved past. The cadence is small; the platform is always reachable.
We know the configurator's complexity has a ceiling. `docs/configurator.md` lays out an eight-phase plan to move from DB-metadata-driven to code-driven configuration — what we'd change, in what order, and what we'd validate at each step. The plan exists for when the work is ready, not before.
Question visibility and field validation live as strings in `config.condition.*` rows, evaluated via `eval()` at runtime. The flexibility is the point; the evaluator is sandboxed to known names so a malformed condition can't break the form.
`product.abstract.extract()` serialises the entire configurator tree into JSON. The jQuery frontend reconstructs the form UI from that payload — visibility, dependencies, computed totals. The backend stays the source of truth; the frontend stays disposable.
Pricing comes out of `product.abstract.composer` — composition formulas that read the customer's answers and produce line items. New product variants don't require new code; they require a few new rows in the composer model.