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

未关闭
  • 哪里不对？
#614 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
24/100
Issue 类型
重构
描述清晰度
需要澄清
活跃度
冷清
技术栈
python
领域
backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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

主要语言
HTML
星标
256
派生
405
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OCA/knowledge 的其他 Issue

查看 OCA/knowledge 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。