How to use bus.notify() called from worker or cron

#1

Has anyone being able to make bus.notify() to work when it is called from trytond-cron or trytond-work processes? I know there is an early discussion from How to use bus.notify() , that explains how to use it, but it only works from the main trytond process. Any one has any idea?

#2

I have never use those setup but the work triggers a notify on postgresql that should be catch by the bus server and trigger the notify correctly.

Coudl you share your setup to see if there is something wrong on it?

P.S: Please note that notificiations does not work on windows nor MacOS clients.

#3

From a cron task, you need to pass the user when calling notify() otherwise nothing will happen as cron are not run in the context of a client.
From a worker, it depends how posted to the queue. If it is from a client request, normally the worker should have the client in the context so it should work out of the box. If it is not from a client request (like a cron task), then you need to specify a user.

#4

Thanks you very much for the tip, I will try specifying an user, but first I need to investigate how to get a list of logged in users and filter them out by certain group.

#5

When calling notify() and specifying the user, the user argument is the “login” field from res.User or something else? I tried passing “admin” and it did not work.

Further investigation, I looked into the XHR bus calls between SAO and the server and it appears that the client is passing as “channel” the value “client” instead of “user”, hence I believe this may be problem why notify does not work even I specified the user. I think some work needs to be done in the code to make this work correctly.

More further investigation, the server’s subscribe function from bus.py does automatically adds a “user:” channel in addition to the one passed by the client, so in theory it should work, but I still don’t know why it doesn’t.

#6

It must be the user id, see Bus — trytond 5.7 documentation

This is expected the user is deduced from the authorization header.

#7

Got it working, thank you!

I should have check the documentation more.