Trigger should be asynchronous

The existing code should not rely on trigger being executed right after create or write. So we could use the queue to post those actions.
But the evaluation should be done at the queue job in case the record state changed.
Also we could replace the action_model and action_function for a selection like in Cron.
Finally it could be also the occasion to implement #4278 (closed).

added notification trytond type::performance + 1 deleted label

What do you mean by the evaluation should be done at queue job?

We currently have a notification_email when the invoice is posted which filters that the state is posted. Currently when posting an invoice with zero amount the trigger is executed because the invoice is first moved to posted state and then moved to paid.

But IIUC, if we evaluate the trigge at queue job, the invoice state will be paid directly and the trigger will not be executed, which for me is not the expected behaviour.

Did I understand it correctly?

added 1 deleted label and removed 1 deleted label

Yes you understood correctly. This will be a change in the behavior but for the best.

I think it is better because how the modularity is managed in Tryton.
My use case which showed the bad behavior is that I got a trigger on sale quotation to send an email. But also I also get the module sale_promotion which applies the promotion on quotation but after the sale has been written to 'quoted'.
So the email is sent with the data before the apply of promotions.

For me, it is clear that trigger should be executed at the end of the transaction. And in your case you should just include the 'paid' state in the trigger condition.

After reading your use case the new behaviour makes sense for me.

assigned to @ced

added 1 deleted label and removed 1 deleted label

added 1 deleted label and removed 1 deleted label

review280971002 updated at https://codereview.tryton.org/280971002/#ps297111002

review280971002 updated at https://codereview.tryton.org/280971002/#ps266881002

I found that it should also be unique be transaction.
Take for example this scenario:

The setup is based on a draft sale with a trigger to quotation.
During the processing, the sale is written multiple times: set a carrier, compute cost etc. For each of this write calls, the trigger will be queued for the same record because the sale is still in draft (eval is False). Finally the sale is written to quotation and a last trigger is queued.
So at the end of the transaction the same trigger record is called for each time the sale was written until the state change.

So for me, we should keep track of the trigger called during the transaction to call it only once.

review280971002 updated at https://codereview.tryton.org/280971002/#ps278731002

review280971002 updated at https://codereview.tryton.org/280971002/#ps289501003

New changeset 7a2b34196f4f by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/modules/notification_email/rev/7a2b34196f4f

added 1 deleted label and removed 1 deleted label

closed

New changeset c9a5103e09bd by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/trytond/rev/c9a5103e09bd

New changeset bdbbdc0ba62b by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/tryton-env/rev/bdbbdc0ba62b

New changeset 17f3841e931b by Cédric Krier in branch 'default':
Cast CurrentTimestamp into timestamp to remove timezone
https://hg.tryton.org/trytond/rev/17f3841e931b

New changeset 9a93b7d87ca2 by Cédric Krier in branch 'default':
Remove unused time import
https://hg.tryton.org/trytond/rev/9a93b7d87ca2