Module architecture

A module is a Python package with tryton.cfg, Pool registration, models, and where needed XML, views, translations, reports, and tests.

Learning objectives

• Declare minimal dependencies and optional integrations. When finished, verify the result with a test record and document ownership.
• Extend models with PoolMeta and always call super(). When finished, verify the result with a test record and document ownership.
• Reuse core models, views, and workflows. When finished, verify the result with a test record and document ownership.
• Use translatable messages and explicit access rules. When finished, verify the result with a test record and document ownership.
• Treat migration and compatibility as design concerns. When finished, verify the result with a test record and document ownership.

Concepts to master

• Declare minimal dependencies and optional integrations.
• Extend models with PoolMeta and always call super().
• Reuse core models, views, and workflows.
• Use translatable messages and explicit access rules.
• Treat migration and compatibility as design concerns.

Guided practice

1. Activity 1. Declare minimal dependencies and optional integrations. Perform it in staging first, record preconditions, and compare expected and actual results.

2. Activity 2. Extend models with PoolMeta and always call super(). Perform it in staging first, record preconditions, and compare expected and actual results.

3. Activity 3. Reuse core models, views, and workflows. Perform it in staging first, record preconditions, and compare expected and actual results.

4. Activity 4. Use translatable messages and explicit access rules. Perform it in staging first, record preconditions, and compare expected and actual results.

5. Activity 5. Treat migration and compatibility as design concerns. Perform it in staging first, record preconditions, and compare expected and actual results.

How to verify the result

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.

Common mistakes

• Confusing save with confirm, post, pay, or close.
• Testing only as administrator and assuming access rights work.
• Changing states or totals with SQL to bypass validation.
• Upgrading without inventory, restorable backup, and post-upgrade reconciliation.
• Documenting only the happy path while omitting cancellation, correction, and exceptions.

Developer perspective

Identify the models, fields, buttons, domains, and access rules involved. Before extending the process, locate the module that owns the rule, review its tests, and preserve invariants through super(). A correct customization must work across companies, languages, permissions, and states.

Production checklist

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.