Anyone who edits Odoo website pages knows the cold-sweat moment: an editor drags a snippet into the wrong place, someone overwrites a carefully-tuned hero section, or a bulk find-and-replace mangles copy across a landing page — and the native website builder has no meaningful undo once the record is saved. Out of the box, website.page and its backing ir.ui.view store only the current arch_db; earlier states vanish the moment you save. There is no per-page timeline, no diff, no "who changed what and when," and no safe rollback. Teams end up keeping shadow copies in documents or restoring an entire database from a nightly backup just to recover one paragraph — an expensive, disruptive sledgehammer for a small mistake.

This is exactly where Odoo native runs out of road, and the gap we build to fill. ECOSIRE builds a made-to-order module that snapshots the arch_db of a website page (and, where in scope, its associated ir.ui.view records, menu entries and SEO metadata) on every save, storing each snapshot as an immutable row on a dedicated website.page.revision model. Each revision captures the author (create_uid), a timestamp, an optional change note, and a stored diff so a non-technical editor sees a human-readable before/after without reading XML. A one-click Restore action writes the chosen snapshot back into the live view inside a single transaction, and — because Restore is itself a save — the pre-restore state is snapshotted first, so a restore can always be undone.

Technically, the module hooks the write path with a write() override (and an @api.model create hook) on ir.ui.view/website.page, computing a content hash so identical saves do not create noise revisions. A @api.depends-driven compute field surfaces the current revision number and last editor on the page form. Access is governed by ir.model.access.csv plus record rules so that viewing history, and the more sensitive Restore action, can be granted to distinct groups (e.g. an editor can view but only a website manager can roll back); every restore writes to the audit trail. Optional configuration — exposed through res.config.settings — controls retention (keep last N revisions, or prune by age via a scheduled ir.cron automated action), whether snapshots also cover attachments and translations (ir.translation / field translations), and whether the timeline is reachable from the frontend editor toolbar via an OWL component or only from the backend. All read/restore operations are available over the standard XML-RPC/JSON-RPC API for integration with your release or governance tooling. It is built and tested against Odoo 17.0, 18.0 and 19.0, works on Community and Enterprise (the website app is Community-grade, so no Enterprise dependency is imposed), and ships as clean, upgrade-safe source.

Because this is build-to-order, delivery follows a short, predictable path: a scoping call to lock exactly which records and metadata are versioned and who may restore, a fixed written quotation, then build and unit testing, UAT on a staging copy of your database, and go-live with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); wider snapshot coverage (translations, attachments, multi-website or multi-company record rules), deeper diff/rendering work, or migration of an existing edit-history dataset increases the quoted scope. You receive a firm fixed price after the scoping call — never a surprise.