Skip to main content
Version: Tryton 7.0 (LTS)

Sources and traceability

Generated pages use tryton.cfg, Python, and XML from the official repository. Editorial guides add practical context but do not replace legal, tax, or accounting advice.

Learning objectives​

  • Official code: https://github.com/tryton/tryton When finished, verify the result with a test record and document ownership.
  • Official docs: https://docs.tryton.org/ When finished, verify the result with a test record and document ownership.
  • Forum: https://discuss.tryton.org/ When finished, verify the result with a test record and document ownership.
  • Every module page links to the exact analyzed branch. When finished, verify the result with a test record and document ownership.

Concepts to master​

Guided practice​

  1. Activity 1. Official code: https://github.com/tryton/tryton Perform it in staging first, record preconditions, and compare expected and actual results.

  2. Activity 2. Official docs: https://docs.tryton.org/ Perform it in staging first, record preconditions, and compare expected and actual results.

  3. Activity 3. Forum: https://discuss.tryton.org/ Perform it in staging first, record preconditions, and compare expected and actual results.

  4. Activity 4. Every module page links to the exact analyzed branch. 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.