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

Abierto
  • ¿Algo no está bien?
#614 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
24/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
HTML
Estrellas
256
Forks
405
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OCA/knowledge

Todos los issues de OCA/knowledge

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.