Tryton - Issues



Title Trigger should be asynchronous
Priority feature Status chatting
Superseder Nosy List ced, pokoli
Type performance Components notification_email, trytond
Assigned To Keywords

Created on 2019-05-10.11:50:24 by ced, last changed by pokoli.

msg49708 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-05-13.08:53:45
After reading your use case the new behaviour makes sense for me.
msg49705 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.19:28:41
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.
msg49693 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.13:48:12
Yes you understood correctly. This will be a change in the behavior but for the best.
msg49682 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-05-10.12:02:10
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?
msg49681 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.11:50:23
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 issue4278.
Date User Action Args
2019-05-13 08:53:46pokolisetmessages: + msg49708
2019-05-10 19:28:41cedsetmessages: + msg49705
2019-05-10 13:48:13cedsetmessages: + msg49693
2019-05-10 12:02:11pokolisetstatus: unread -> chatting
messages: + msg49682
2019-05-10 11:59:48pokolisetnosy: + pokoli
2019-05-10 11:50:24cedcreate

Showing 10 items. Show all history (warning: this could be VERY long)