Project

General

Profile

Actions

Feature proposal #6384

closed

Implement support for conversations

Added by krileon over 7 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
-
Start date:
23 December 2016
Due date:
% Done:

100%

Estimated time:

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


Related issues 1 (0 open1 closed)

Precedes CB Activity - Feature proposal #8264: Implement WebRTC voice/video callsRejectedkrileon26 December 201626 December 2016

Actions
Actions #1

Updated by krileon about 7 years ago

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.

Actions #2

Updated by krileon about 7 years ago

  • Subject changed from Implement support for chat to Implement support for conversations
Actions #3

Updated by krileon almost 7 years ago

Conversations should be a new database table, but simply extend the existing Comment class.

Actions #4

Updated by krileon over 6 years ago

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.

Actions #5

Updated by krileon over 6 years ago

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.

Actions #6

Updated by krileon over 6 years ago

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

Actions #7

Updated by krileon almost 6 years ago

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.

Actions #8

Updated by krileon over 5 years ago

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

Actions #9

Updated by krileon over 3 years ago

Actions #10

Updated by krileon over 2 years ago

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

Actions

Also available in: Atom PDF