oca/knowledge

This repository is an Odoo add-ons collection centered on document and knowledge management. The architecture is modular: each top-level package is a separate Odoo addon with its own __manifest__.py, Python models, XML views, security rules, translations, tests, and static assets. The shared runtime is the Odoo 18 server; there is no separate backend service.

1. Core domain model: document_page

This is the main knowledge-base subsystem. It defines the document.page model and related history/category/report/wizard logic, plus kanban UI customizations. It is the foundation that other addons extend. The main data flow is user edits in Odoo views and wizards → ORM writes to document.page / history records → rendered views, reports, and search/display logic.

2. Knowledge workspace and access scaffolding: document_knowledge

This addon provides a knowledge-oriented entry point around attachments and pages. It includes configuration models, access/security XML, demo data, and view definitions. It acts as a higher-level feature layer over Odoo documents/attachments, rather than introducing a new standalone service.

3. Page access and authorization variants

Several addons customize who can read/write pages:

• document_page_access_group and document_page_access_group_user_role add group-based access behavior.

• document_page_group defines access groups on pages.

• document_page_approval adds approval workflow semantics and mail template/data.

These modules primarily change security boundaries and page lifecycle, not the core content model.

4. Page metadata and classification

document_page_tag adds tags/keywords for lookup. document_page_reference adds page references and includes a small frontend editor asset plus a migration. These are enrichment layers on top of document.page, enabling discovery and cross-linking.

5. Linking pages to business objects

Several addons attach document pages to existing Odoo business models:

• document_page_partner links pages to partners.

• document_page_product links pages to products.

• document_page_project links pages to projects.

• document_page_project_task links pages to tasks.

This architecture is important: pages are not isolated documents; they become contextual documentation attached to operational records through ORM model extensions and form/view inheritance.

6. Attachment handling subsystems

There are three attachment-focused addons:

• attachment_preview adds preview support for attachments.

• attachment_zipped_download lets users download attachments as a ZIP; it includes a controller for HTTP download flow and model extensions to the attachment action.

• document_url turns an attachment-like record into a URL-backed attachment, with a wizard, XML views, SCSS, and frontend widget.

These modules sit at the boundary between Odoo’s attachment model (ir.attachment) and the client/UI, modifying how binaries are viewed, downloaded, or represented.

7. Frontend/UI layer

Frontend code is concentrated under each addon’s static/src. The repo uses Odoo’s modern JS module format (*.esm.js) plus XML templates and SCSS. Notable UI customizations include:

• attachment_preview integrating ViewerJS and custom web view/mail patches.

• document_page kanban controller/view overrides.

• document_url URL widget/template.

These assets are loaded by Odoo’s web client and alter user interaction without changing the deployment topology.

8. External/embedded client library usage

attachment_preview vendors ViewerJS under static/lib/ViewerJS. That library is embedded in the addon and used client-side for document rendering/preview, including PDF-related viewer assets. This is a packaged frontend dependency, not a remote service.

9. Server-side extension points

Most behavior is implemented through ORM model inheritance, view inheritance, and occasional controllers/wizards/hooks:

• Models extend ir.attachment, document.page, project.*, product.*, etc.

• Wizards handle actions like creating menus or showing diffs.

• attachment_zipped_download adds an HTTP controller.

• document_page_approval includes hooks and mail template data.

The repo’s architecture is thus “Odoo extension by composition”: model mixins and inherited views are the primary integration mechanism.

10. Security and configuration boundaries

Security is explicit per addon through security/*.xml and ir.model.access.csv. Some addons also ship configuration views/models (document_knowledge, document_knowledge/res_config.py). This means access control is part of the module boundary, not centralized in one shared security layer.

11. Localization and packaging

Every addon has i18n/*.po catalogs, making translation a first-class part of the UI architecture. pyproject.toml, lint configs, and GitHub workflows show this repo is packaged as a maintained OCA addon suite with automated checks, but those do not affect runtime behavior.

12. Test surface

Each functional module has its own tests under tests/, often covering model behavior, security, wizards, and view-related flows. The test layout mirrors the module boundaries, which is useful for understanding where each feature’s responsibility starts and ends.

Overall shape for a diagram: Odoo server at the center, with document_page as the core domain, attachment-related addons on one side, business-object link addons around it, and UI/assets/security as cross-cutting layers. The main data objects are document.page, ir.attachment, and linked business records like partners, products, projects, and tasks.