Requests without topics - another entry to threading

[mrsimpson]

Replacing #179 based on the last product refinement

Motivation

Currently, requests are the heavy threads based on topics only.
This limits their usage and requires casual users to understand the data model and room types. In order to allow more flexible processes for asking a question (#145, #178), the request must not only be created on the basis of a topic but also on any public or private channel.

Also, people need to join a channel in order to create a thread which is cumbersome for newbies and in some cases unwanted (private groups shall remain privatem, still someone might want to ask a question for it) .

Purpose

As a user who wants to ask something, I want to start a question/request/thread for any room without joining the room in order to get help from those experts.

Threads are a common feature across multiple chat platforms and mostly accepted by users. There's a loooooong ungoing discussion RocketChat#1112 how to implement threads in RC.

This issue is about enabling threading without the need to use the fullblown request/topics mechanism.

Tasks

• provide a simple "create thread" UI. For this, the createRequest template can pretty much be copied. However, it should only contain one single input for the initial message.
• As parent room, a configured room (by default "General") should be selected. This selection might optionally be changed by the user by showing the input field.
• Keep the room type if based upon c or p
• It shall be configurable whether threads shall be enabled or not. If disabled, the buttons from the action menu and the home screen starter shall be hidden.

Remarks

• A thread shall only be identifiable as such by having featuring a parentRoomId and optionally a originMessageId.
• Technically, the package should not focus on "questions" or "asking something", but it shall be as independent from Assistify as possible - and thus contributable. The UI texts can be overwritten for Assistify with "Ask a question" (instead of "create a thread")
• As long as the custom room types exist, there will be tabs on the creation screen. The removal of requests and topics is not necessarily part of this issue. It's only important that when implementing this feature, there is not explicit dependency to requests and/or topics. However, the order of the room types could be changed in order to make the requests less prominent.

[mrsimpson]

@janrudolph your feedback, please.

[mrsimpson]

Technical remarks

• Start a new package assistify:threading
• Potentially, start from a plain branch of RC develop
• Copy the request creation screen, the method to create a request and other artifacts related to threading to this new package
• We may leave out the custom rendering of the thread created message as this is another dependency towards a modification
• Make it build (remove "syntax"-errors)

[janrudolph]

@mrsimpson I am missing the part of defining the parent room. Do we configure it in the admin backend?

By the way, UI design of "ask a question"

optional: right sidebar shows a hint that a knowledge base will be present soon

[janrudolph]

@mrsimpson Is the implementation of the knowledge base in public and private channels also scope of this issue?
Edit: No, it is not. Please see #419

[ruKurz]

Should be resolved by releasing less-is-more