Skip to main content
Version: Tryton 7.0 (LTS)

8. Wizards, reports, and tasks

Tryton 7.0 · versioned practical course

Objectives

  • choose between wizard, report, queue task, and scheduled action
  • pass explicit data between wizard states
  • keep long work outside interactive requests

Mental model

A wizard coordinates a conversation with the user. A report renders records. A queue task performs asynchronous work. A scheduled action starts recurring work.

Guided practice

  1. Define the user decision and its confirmation screen.
  2. Use StateView for parameters and StateTransition for server work.
  3. Return an action only when navigation or output is required.
  4. Queue slow or retryable processing.
  5. Make reports and tasks reproducible and permission-aware.

Minimal example

from trytond.model import ModelView, fields
from trytond.pool import Pool
from trytond.wizard import Button, StateTransition, StateView, Wizard

class LoanDoneStart(ModelView):
"Complete Loans"
__name__ = 'library.loan.done.start'
note = fields.Text("Note")

class LoanDone(Wizard):
"Complete Loans"
__name__ = 'library.loan.done'
start = StateView(
'library.loan.done.start',
'library.loan_done_start_view_form', [
Button("Cancel", 'end', 'tryton-cancel'),
Button("Complete", 'complete', 'tryton-ok', default=True),
])
complete = StateTransition()

def transition_complete(self):
Loan = Pool().get('library.loan')
Loan.done(self.records)
return 'end'

How to read the example

Register wizard and state models with the proper Pool type. Do not use a wizard merely to hide a model method; use it when the user must provide or confirm information.

Exercise

Add a confirmation summary, a printable receipt, and a queued notification. Test retries without duplicate notifications.

Run the exercise first with a minimal valid case, then add an invalid case and turn both into repeatable tests.

Verifiable result

The wizard respects active records and permissions, the receipt is deterministic, and slow notification does not block the form.

Common mistakes

  • trusting active_ids without validation
  • performing huge jobs in a transition
  • mixing report rendering with business mutation
  • creating non-idempotent retryable tasks

Ready-to-advance criteria

  • I can explain the concepts without looking at the code.
  • Valid and invalid cases have tests.
  • I tested with a non-administrative user.
  • I know how to upgrade and restore the training database.

Version and references

Series 7.0 requires at least Python 3.8 according to official metadata. This official branch still carries historical metadata in setup.py; preserve series compatibility while preparing custom packages for standard python -m build builds. Do not confuse this historical minimum with the Python version certified by your organization.

This edition pins examples and dependencies to series 7.0. Check the official 7.0 tutorial, server API, and source branch before moving a pattern to production.