[IDEA] Deprecate document.page.history and use base_revision

Open
  • Is something wrong?
#614 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
24/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Quiet
Tech stack
python
Domain
backend

Research direction

The issue identifies document_page and base_revision but gives no files, tests, or implementation entry point. Start by reading both modules’ revision models and the history logic, then assess how inheritance and existing document data would be handled. Done means document.page uses base_revision and the old history model is removed, with revision tracking covering document context as well as content.

Written by the indexing model from the issue text.

Description

enhancement

Is your feature request related to a problem?

  • Document_page_history handles only changes in document content.
  • In ISO (and most other certification schemes, I guess) changes in the context of the document (aka scope, use, applicability, responsibility) should also create a new version.
  • Document history has been problematic working ON / OFF between Odoo versions

Describe the solution you'd like
Remove document.page.history completely and replace, inheriting from base_revision.
Using base_revision as the foundation for document revisions in the document_page module would simplify the architecture considerably while also making revision tracking more complete and consistent.

Today, document.page.history duplicates part of the data model and requires explicit logic to decide which fields are copied into history records. This creates several limitations:

  • only selected fields are revisioned (content)
  • schema changes must be mirrored manually
  • custom modules adding fields are not automatically revision-aware
  • history synchronization logic becomes harder to maintain
  • revision consistency depends on custom implementation details

By refactoring document_page to inherit from base_revision, revisions would become model-native instead of relying on a parallel history model.

Key advantages of this approach:

  • Automatic revisioning of all fields
    Any stored field added by OCA or third-party modules automatically becomes part of the revision system without additional code.
  • Elimination of duplicated models
    Removing document.page.history reduces maintenance burden and avoids keeping two partially synchronized representations of the same document.
  • Better extensibility for OCA ecosystem modules
    Modules extending document.page would gain revision support automatically, including custom metadata, categorization, workflow fields, attachments, references, etc.
  • Consistent behavior with other OCA modules
    base_revision already provides a standardized revision workflow used across the OCA, improving predictability and reducing custom code.
  • Reduced upgrade complexity
    Future field additions or refactors would not require updating history-copying logic or migration scripts for duplicated fields.
  • Improved auditability
    Since revisions are based on the actual business record structure, the revision history becomes more complete and reliable, thus you get a better point-in-time view of the documents.
  • Cleaner ORM integration
    Access rights, computed fields, tracking behavior, and inheritance patterns remain centered on a single model architecture instead of a shadow history model.
  • Easier maintenance long-term
    Less custom revision logic means fewer edge cases and lower risk of history inconsistencies (issues such as #565).

This refactoring would effectively shift the module from a “manual snapshot/history table” approach to a generic ORM-level revision mechanism, making the revision system both more powerful and easier to maintain.

Furthermore any logic that needs to be used for documents (such as summary of changes) can be added to base_revision so all modules that inherit from it can use it if it makes sense for them.

Describe alternatives you've considered
Duplicate all fields of document.page to document.page history and keep track of changes.

Additional context
This is just a use case investigation and I haven't reached deep in implementation details.

What do you think @etobella @pedrobaeza @victoralmau

Dominant language
HTML
Stars
256
Forks
405
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OCA/knowledge

All issues in OCA/knowledge

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.