We need the option to display system messages in Tryton.
The purpose is to inform user on activities, problems or upcoming events with a pop-up message.
As example, an important message for the Demo-DB could be ’Dont change the language of the admin-account!’ or 'The Demo-Database is reset each night at 0200 CET’
The system message should be displayed exactly 1 time to the user:
at time of login, if a message is available
immediately, in case the message is created while the user is already logged-in.
It should be possible to enter more than one system message. All available messages should be displayed in the same pop-up, together with the user (name|ID) who created the message.
There should be a possibility to set an expiry date and time for each message
System message maintenance should be part of the admin menu, and only with admin authorisations
For me, the Tryton protocol (json-rpc) is not designed for such feature.
Also I don’t think we must reinvent the wheels. It will probably better to use email notification or a XMPP server. Indeed I think a feature to allow to create/publish resources on a XMPP will be a very good improvement.
You mean Tryton is not able to display a pop-up?
Neither Email nor XMPP are able to fulfill the requirement to inform a user immediately on the system. Both are aynchronous and require external software, additional you need contact data that you may not even have (e.g. for the demo database).
As it is a one-way communcation (Admin/system to user) it is neither big effort, nor reinventing something.
That’s not the point. What you describe is polling notification. And yes Tryton is not able to do that with the current protocol without being insanely resource consuming. That’s why the res.request was removed in 3.0.
For such thing, tools already exist and we must not reinvent the wheels: Email and XMPP.
I’m not sure what you mean. This term is so often miss-used. But if you mean that notification will not be direct. This may be true with email but for XMPP is a protocol build for direct notification.
We don’t really care about demo database.
This is false. It is a huge effort to implement it correctly. So we must build on the existing.
But now, it is probably possible to re-use the new note object to have it linked to a generic/global object (or empty reference for global). This will not be direct because it will require a refresh from the user but it could be part of a startup dashboard.
Technically speaking you are right regarding XMPP. But it requires additional software to run at the same time. If this is not running it becomes highly async.
Sounds good. Polling would be the wrong way. It is sufficient if it is displayed on a user interaction.
Means any interaction checks for new and undisplayed messages in a first step, and sets the message to ‘read by this user’ after the user presses OK. That should make sure the message is not displayed anymore during the actual session.
This will be so much performance killing that it can not be envisaged.
That’s why for me, the correct way is by pushing and so it must be another protocol than HTTP which is request based.
For the server part, I think it is the only way because it must support pub/sub protocol, it should be distributed (as trytond can be distributed).
But maybe there is simple XMPP library that could be included in the client without too much pain.
Any way, I don’t see it as an issue to have to run different software client and server side. We already are using email and XMPP is a great tool for enterprise.
Not sure if I get your points completely.
I dont think that it is performance-intense. There is communication between client and server, and it is one database call to verify new system messages. This can be fetched e.g. when the user saves a dataset or calls a new transaction.
You need to explain this more in detail: If I send a request to the server to do something, the check on a new system message happens in the backend. As long as no message is available, no additional communication takes place.
If a message is available, the information about a new message can be submitted with the result of the request. Or as separate ‘answer’.
So I don’t see the performance issue
You can not do something else during a request otherwise you can break the transaction. So you need to do a second request.
Also I think this is a poor attempt of implementing of a push notification because it will not work if user doesn’t perform requests. It would be better supported by the XMPP protocol.
I think this is a good approach to this requirements, and provably its not so hard to implement because there are plenty of libraries that implement XMPP protocol.
It could be a client plugin to make it optional
Of course someone could write a XMPP client as a plugin of tryton but it will be very minimal client.
The server part should really separated from trytond processes.
I think this topic could be replaced by Real-time notification.
Indeed the XMPP plugin is still a good idea but probably more in the direction of building a bot. It will not fit well in our new environment which is partially desktop and partially web.