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

Aperta
  • Qualcosa non va?
#614 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
24/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
HTML
Stelle
256
Fork
405
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OCA/knowledge

Tutte le issue di OCA/knowledge

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.