Chat functionnality on resources


(Nicolas Évrard) #1

Rational

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).


Crowd-funding campaign
(Cédric Krier) #2

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).


(Nicolas Évrard) #3

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 :adult: for the user and :family_woman_woman_boy: 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 :wink:).


(Cédric Krier) #4

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.


(Nicolas Évrard) #5

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 :stuck_out_tongue:.
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. :man_shrugging:


(Cédric Krier) #6

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.


(Sergi Almacellas Abellana) #7

Maybe we can use @ for user and @@ for group. I don’t think it’s very common to have usernames starting with @.

I think using different channels on the same bus is the right approach.


(Cédric Krier) #8

And what about using # to create tags on the fly like twitter and let user subscribe to notification to any #


(Sergi Almacellas Abellana) #9

Nice idea! This will allow the users to create their own groups so it gives more flexibility.