A lot of the communication in the company is quick and dirty chat like discussion about a specific resource (Sale, Purchase, …). Tryton should have a way to easily integrate those discussions with the workflow of its users.
Those messages would be different than the notes as they would not be related to the resource itself but rather to the handling of the resource (or anything else) by people working in Tryton.
Proposal
With the introduction of the Real-time notification it’s now possible to allow people to communicate about a resource using a chat-like technology.
We propose to add a new model ir.chat.message that will store those chat message and their reference to the resource which it concerns.
Parsing the content of the messages to allow for notification using the @ sign looks like a good idea but it will probably require another mechanism for storing more permanent notifications. I wonder if just like in discourse those @ notifications shouldn’t also notify group of users (maybe using another prefix). Adding link to other database resource is also something that we can think that user will want to use.
Implementation
The ir.chat.message model will use four RPC methods:
get(resource, timestamp, direction): which will retrieve messages either before a date or after a date.
post(resource, message): which will post a message on the resource chat, the clients will be then be notified a new message has been posted and will thus trigger a call to get.
subscribe(resource, session): which subscribe a user session to a resource
unsubscribe(resource, session): which unsubscribe a user session to a resource
The notification of the client (in order to call get when a new message is available) will use the bus from the notification blueprint.
The actual standard in communication chats seems to be to put the author messages on one side of the chat window and the messages of the other participants on the other side. I think that using the same behaviour is a good idea.
As in GTK using a treeview is not efficient when storing a lot of widgets, a different orientation has been taken by Polari. They are using a TextView with specific tags to denote the irc nicknames and time or hours. This way of doing would also suit well the way we could do in sao (a divwith some p in it or something like that).
The notification/long_pooling should be carefully designed. I think the chat should not be active by default when a document is opened but only when the user open the chat window. This will allow to limit the notification and avoid to create new request each time a document is opened. For me, user wants to have real time chat only on document they stay on for a long time.
It is probably better to have another prefix because we can not guarantee uniqueness between user name and group. So # seems to be the natural choice.
But also we do not have a short name for group (the name has often spaces) like we have login for user. A new field should probably be added.
I think it should just support general URI.
I may be improved by allowing to store a binary field which will be display as an attachment in the conversation. The binary will be downloadable by clicking on its icon. A preview of image could also be put in the view.
It will be good to describe their signature now.
I would even say that the author messages are on the right (or left in RTL).
When we discussed it I thought we reached an agreement that we should use the same process as for the notification but using another kind of message.
The idea I have is to register the client and its session when opening the chat window and unregistering it when the user close the window. The post method will then use this information to NOTIFY (using another method then the one from the notification blueprint) the users subscribed to the resource.
I guess discourse has some validation but I find it strange to use a different symbol as the ‘@’ pretty much convey the meaning of I speak to someone. Maybe we can use the autocompletion to propose both name with a different sign (eg for the user and for the group).
But it would require to have some kind of syntax for the messages.
We could also have autocompletion there (if we want eye candy we can put as much sugar as we can ).
Of course we must we should do like that. But it should be stated in the blue print and it should be described how the information about the chats opened is passed.
But I was referring to when the long_polling is started/restarted/stopped when a chat is opened/closed. I think when the chat is opened, we should cancel (if possible or start a new request) and when the chat is closed we can do nothing (and let the request stop by timeout).
I do not think it is correct to do that on the server side. For me, the long polling request should have, in addition to the bus session id, a list of chat resources. Then the bus will dispatch the notification message coming from a post to the right long polling requests.
I will not be surprise that a user or a group has the same data structure.
Not sure the emojicon will be rendered correctly in GTK textview.
And it does not really solve the duplicate name between group and user.
I’m not sure it will be very useful. I guess user will just use copy/paste the document URI.
I thought about that but my concern with this is that it is mixing the bus code with the code related to the chat functionality. I think it should be isolated in another object, hence the idea to reuse ir.chat.message.
They are two different tables in that database:
and
but I didn’t found the validation code.
The idea would be to have a specific syntax that would be rendered accordingly.
It was a sally in fact .
But with a specific syntax like Sale:id it could be rendered with the icon of the sale and next to it it’s rec_name.
What’s the point? It will just make the design more complicated.
Indeed instead talking about resource here, we can just talk about channels. So the notification manage channels which can be for now: bus session id or chat on resource id. But the bus should see it only as channels.
I do not see the point to introduce a new syntax. And more over user does not know about id.
I am in support of this, with the look of things how do I get to be able to contribute from my end to this, because I blive this modules should have been made since
This is an area of development that I’ve been contributing to for many years. I’d suggest trying to engage with other groups that already develop chat solutions and I’m happy to help facilitate that. This can help to avoid reinventing the wheel.
I would look at Matrix (opensource distributed chat system) and develop a bot based on Maubot or something from the ground up. The bot is connecting to Tryton and based on certain keywords you can ask Tryton for information. You can create a room specifically for that particular record etc. You can even think of integrating the rooms into the Tryton client, which then needs a new widget.
Yes that is true I don’t know of any standalone or ready made maybe we can try to integrate the user interface, if any I am thinking us having like the setup to connect to the ip and port from the client which would be set by the admin the under it we can then have the main chat box and then users just input their user name and password again.
A lingering idea I have is to use XMPP and having documents as resources in their roster where people can chat in their IM client as they are used to do.
But there are issues with access rights and persistence. And also it’s indeed an area where we’re not knowledgeable at all.
Looking at Matrix, my idea would be to create a room for each record / document / resource so you have a clear distinction between the different records / documents / resource. Also rights who can join the room can be managed and you even should be able to invite your customer to join the room.
For example, when you have a quotation, you can set up a room where you put in the sale document and other resources. You invite your colleague and your customer and start chatting (or talking because Matrix supports VOIP) about the quotation. Using several Tryton specific defined keywords like /tryton show saleline 2 you can also interact with the sale data itself. When everybody is happy a keyword like /tryton confirm sale will set the sale to state confirm.
When everything is done (order delivered and payed) the room can be discarded or cleaned up (redacted) and the result stored in the Tryton database itself as history.
for the user and 
for the group).
).
.