Missing Omnichannel features / bridges for GSoC-2020 projects

[renatobecker]

We are about to start the GSoC season(2020) and this year we have at least 3 projects that aim to implement new Omnichannel Apps:

• Dialogflow/RASA chatbot integration(Rocket.Chat)
• Salesforce live agent integration(Viasat)
• Salesforce CRM integration(Viasat)

Even though we already have a few Omnichannel Apps implemented and working very well, we'll need to add/extend a set of new features/bridges in order to develop the 3 news Apps mentioned before.
The discussions about the spec of each project have already started, the students are getting familiar with the Apps-Engine as well as our partners that will be the mentors of some sponsored projects.
Therefore, I'm going to describe what features are still missing on the current version of the Apps-Engine and will be necessary for the execution of the projects:

- Ability to create new users and make them Omnichannel agents:
We'll integrate Rocket.Chat with an external system that will be responsible for determining which agent will serve a given omnichannel room that will be identified by some information stored in its custom fields. Initially, the users may not exist in Rocket.Chat, so the App will need to create it as well as to set the new user as an Omnichannel Agent. Also, the Apps-Engine will need to allow the storage of User's custom fields, in addition to finding a specific User based on a custom field value.
We will need to be able to find users by custom fields because we'll need to store the external application unique ID, this is the information that will identify the Rocket.Chat User/Agent which will serve Omnichannel conversations. the following Rocket.Chat features need to be available to the Apps through the Apps-Engine:

• Create new Rocket.Chat User
• Call Livechat.addAgent method
• Assign other roles to the user, such as the bot role since the agent's won't be online in Rocket.Chat and the Omnichannel routing system allows offline agents since they have the bot role

- Add assignAgent and unassignAgent event handlers
The Apps will need to be notified when an agent is assigned or unassigned from an Omnichannel room. To achieve this the Apps-Engine will need to support event handlers on the following Rocket.Chat methods:

• RoutingManager.assignAgent
• RoutingManager.unassignAgent
  In both event handlers, the Apps will need to get the room and agent information.

- Ability to listen when a new Omnichannel conversation starts
An App may need to be notified when a new Omnichannel conversation starts in order to execute specific tasks. Currently, we already support the LivechatRoomClosedHandler, now we need to extend something like LivechatRoomStartedHandler. This event happens here:

• createLivechatRoom method

We were aware that we'd need to extend new Omnichannel features sometime, now we have very important reasons to put some effort into these demands, otherwise, it wouldn't be possible to execute the GSoC projects that have Apps-Engine dependency.

[d-gubert]

The only feature that needs further discussion here is user creation; that's a rather sensitive subject for us because it could be easily abused, and we're not really sure how to prevent it.

For instance, in the cloud environment, the total count of active users impacts how much the workspace is going to be charged. For Apps subscriptions, the total count of active users will determine whether an app will be blocked for the workspace or not.

So enabling apps to add users to a workspace can have a pretty bad impact in some aspects.

Some consideration has been giving towards:

• Allowing apps to do it unrestrictedly nonetheless; admins should have a full understanding of what an app is able to do upon installation; this would require us to show the admin some sort of feature description for the app (or even a disclaimer of what every app is able to do) before it is installed
• Restricting apps to creating X users in a time frame; this is a rather weird one, as it would be difficult to measure what is an acceptable creation limit; this would require us to actually implement the limit enforcing logic as well

@rodrigok @sampaiodiego @graywolf336 @geekgonecrazy would like your inputs on this one

[sampaiodiego]

Giving apps administrator capabilities (like managing users and omnichannel agents) is something that we should look very carefully as it opens a breach for evil or hacked apps to take control of rocket.chat instances.

can you look into this requirement with a different perspective?

there are two alternatives that come into my mind:

• add the ability for apps to fake omni channel agents. so in this case the app needs to be assigned as omni channel agent and when receiving a livechat the app itself will get the agent information (name, avatar, etc) from the external provider and present those info on the livechat widget. so the final user will only see the "real" agent information but behind the scenes its the app user that is associated with the live chat.
• an other alternative the app consuming rocket.chat APIs to manage everything. the REST API is robust, well tested and can be used by anyone with the required credentials. to help in this scenario we could think on making a bridge between rocket.chat's REST API and the apps engine, so an app would not require to make a real HTTP request doing a round trip over the internet. Other thing that could help in this scenario would be a special type of setting to get the authentication credentials, like a button "use my credentials to make HTTP requests" or something like that.

[renatobecker]

• an other alternative the app consuming rocket.chat APIs to manage everything. the REST API is robust, well tested and can be used by anyone with the required credentials. to help in this scenario we could think on making a bridge between rocket.chat's REST API and the apps engine, so an app would not require to make a real HTTP request doing a round trip over the internet. Other thing that could help in this scenario would be a special type of setting to get the authentication credentials, like a button "use my credentials to make HTTP requests" or something like that.

Thanks @sampaiodiego for the feedback.
To be honest, the second alternative you mentioned is something I had in mind as a Plan B, so for sure, having a sort of bridge to our REST API would solve the main problem, that is related to creating User/Agent stuff.
As you describe, we can do exactly we need through the REST API, having a bridge for this purpose would be amazing.

Thanks.