Feature proposal #6384
closed
Implement support for conversations
Added by krileon over 8 years ago.
Updated over 3 years ago.
Start date:
23 December 2016
Description
This should basically be comment streams created on the fly. Needs to have type detection support (e.g. cyz is typing..). If possible support group conversations. Needs to also support a history limit (e.g. auto-delete any messages older than xyz days).
This basically is also private messaging. Should be called "Conversations" instead of chat or private messages. Ideally should allow for more than 2 usages to converse, but unsure how to structure that asset at this time.
- Subject changed from Implement support for chat to Implement support for conversations
Conversations should be a new database table, but simply extend the existing Comment class.
Should have an icon next to the notifications. Needs to also have a bar at the bottom of the page (optional, default disabled) output by the CB Activity module for quickly accessing conversations.
Should have an inbox endpoint to view all conversations for the asset.
There also needs to be 2 separate refresh params. One refreshes the stream (e.g. check for new entries) when the conversation isn't open (e.g. for the icon like notifications) and one while the conversation is open (chatting with someone). This ensures the general new notification isn't polling constantly.
Does this really need to be a copy of the comments table? Comments queries only output comments from the specific asset. It doesn't have the same problem as notifications. Conversations table could just be a relationship table. So for example it determines who can access and see the conversation whereis the conversation is actually just a comment stream with an asset of "conversation.CONVERSATION_ID".
After thinking this over it should absolutely be a clone of the comments table. We do NOT want to run the risk of comments and conversations being mixed in a stream. Isolating the information to 2 separate tables is the safest option. Basically same approach as Notifications.
Use the following storage structure:
_comprofiler_plugin_activity_conversation
_comprofiler_plugin_activity_conversations
The conversation table simply stores pointers for conversations (relationship table basically). It would be something like the below.
id | user_id | asset
Conversations table is the actual messages. Basically like comments, notifications, etc.. table. The asset that the conversation table is pointing to would be the asset tied to the conversations table asset column. Review redoing notifications to also be a relationship table usage just like this, but would need to consider support for global (non-replicated) notifications usecases (and possible same for discussions to allow basically chat rooms).
- Status changed from Assigned to Rejected
- Target version deleted (
6.0.0)
- % Done changed from 0 to 100
This will be the next itineration of Private Message System. No need to have 2 communications implementations. The PMS implementation will be free as it is a part of core CB.
Also available in: Atom
PDF