Looking For Best Practices for Custom Module Development in Tryton?

Support Developer
1

Hi everyone,

I am currently working on a custom module for Tryton and wanted to ask the community for advice. I have gone through the official documentation and followed some examples.., but I want to make sure I am sticking to best practices—especially around model design, field inheritance, and keeping everything upgrade-safe.

A few specific questions I have:

Are there any recommended naming conventions or structure tips to follow for custom modules: ??

How do you handle changes in existing models without breaking future updates: ??

What’s the cleanest way to extend workflows or business logic in a maintainable way: ??

If any experienced developers have suggestions, examples, or can point me to useful resources or existing module patterns.., I would really appreciate it. I have already gone through this https://discuss.tryton.org/t/preparing-for-module-developmentmachine learning course in chennai but still need some more help.

Thanks in advance !!

Marcelo Salas

2

There are not official but I can share what we do at B2CK.
For the name of new model, we try to include the name of the custom module in it to be sure to avoid future naming collision. And we use natural name for their fields.
To name custom fields added to a standard model, it depends if the field name is obvious (for example if it will be added in standard, it will be the same) we use the natural name. But if it is not obvious (for example the definition is a specific interpretation for the custom module), we add the module prefix in the name (but not in the label).

We add tests that should detect such issue.

  • Always call super when extending an existing method.
  • Add assert for every assumptions
  • Try to alter the existing result instead of building a new result

Now adding new transition may be a little bit difficult especially if you want to make them mandatory. I would advise to try to solve the issue differently if possible (like using button rules, other models, wizard etc.).

3

According to my experience developing custom modules for Tryton, we follow some practices that help us build better, upgrade-safe, and maintainable modules. I hope these ideas are useful for you:

:one: Development Environment

We have implemented a custom environment to support our development workflow, using tools for automation, testing, and deployment:

  • Docker / docker-compose / Rake / flake8
    These tools help us standardize development, enforce code style, and make deployment predictable.
  • End-to-end testing environment (using .rst scenarios)
    This allows us to follow Test-Driven Development (TDD). Tryton provides strong support for writing tests that ensure your customizations are reliable and won’t break with upgrades.
    :backhand_index_pointing_right: Tryton Testing Documentation
  • Live development environment
    We maintain an environment where we can see our progress directly in the Sao client, use sample datasets, and adjust the user interface and user experience as we go. This is especially useful for verifying workflows and UI design early.

:two: Recommended Naming Conventions & Structure

Here are some practices we follow:

  • Module names: Use a clear and descriptive name that reflects your domain or business logic (e.g., company_project, accounting_extension). Avoid generic names.
  • Model names: Use namespaced names where possible (e.g., company.project.task), so they won’t clash with future Tryton core modules or other custom modules.
  • Field names: Be consistent and descriptive (e.g., is_active, approval_date). Prefer underscores and avoid abbreviations unless they are widely understood.
  • Folder structure: Follow the standard Tryton module layout, with clear separation of models/, views/, tests/, locale/, etc.

:three: Handling Changes to Existing Models (Upgrade-Safe Customization)

:white_check_mark: Always extend models using class inheritance (metaclass=PoolMeta) rather than modifying core files.

:white_check_mark: When adding fields, choose names that won’t conflict with future Tryton versions (this is where namespacing helps).

:white_check_mark: Write migration scripts or data update methods for cases where your changes affect existing data (e.g., filling new required fields).

:white_check_mark: Write tests for any model extension to ensure your changes work after upgrades.

:four: Extending Workflows or Business Logic

  • Use on_change, validate, button actions, or State fields to extend business logic cleanly.
  • Avoid monkey-patching core methods; instead, override and call super() so you build on existing logic rather than replacing it.
  • When introducing new workflows (e.g., approvals, statuses), consider using Workflow state fields or separate models to encapsulate the new logic.

:five: Useful Resources

:light_bulb: Final tip:
Tryton is designed to encourage clean and modular code. The more you align with its patterns (inheritance, modularity, testing), the easier upgrades will be!

4

Un ejemplo de como usted podria mejorar el desarrollo de sus modulos, para este caso

usted podria extender el modulo oficial Party de tryton usando:

Party(metaclass=PoolMeta):
    pass

En tryton es muy comun ver este tipo de extension.