Repository navigation
[Tracking] Okta login with widget and CX for transferbot #1332
Description
Cameron working on another story for this on the jira board.
Metadata
Metadata
Assignees
Labels
No labels
{{ message }}
Cameron working on another story for this on the jira board.
Activity
ear-dev commentedon Nov 10, 2022
@Shailesh351 can you please consult with @csmith14 about which API might allow him to set a value in local storage on the client, that the livechat widget can respond to. i.e. we need a mechanism to respond to a payload_action == "display_okta", such that we can open a new webview in the iframe.
ear-dev commentedon Nov 10, 2022
https://github.com/WideChat/Rocket.Chat.Livechat/tree/develop/src/store
csmith14 commentedon Nov 10, 2022
@Shailesh351 @bhardwajaditya
So we handle all these DFCX 'action' payloads here: https://github.com/widechat/apps.dialogflow/blob/CWS-1299-okta-component/lib/payloadAction.ts#L44
All the current handlers change the room state using an existing apps-engine API (close chat, transfer department), set/update room custom fields, update persistent data, pass message content along from DFCX to the session, or a combination of those.
I had planned to do:
DFCX 'display_okta' payload -> DF App updates room custom field -> Livechat widget gets notified of custom field change -> Livechat widget updates store state -> Okta component is rendered
However, the 'Livechat widget gets notified of custom field change' functionality doesn't seem to exist.
It seems the above flow doesn't adhere to the way the app handles similar events, and I would really like any suggestions.
Thanks
ear-dev commentedon Nov 14, 2022
@bhardwajaditya @Shailesh351 do you guys have any ideas about the best way for @csmith14 to implement this?
Shailesh351 commentedon Nov 14, 2022
@csmith14 Can't we use the message custom field? We are using it to disable input. We couldn't use the message custom field for typing because of the frequency of typing messages for the session. But in this case, I think it's okay because it will be one time.
csmith14 commentedon Nov 14, 2022
Isn't that a bit of an anti-pattern either way? Is there no apps-engine/livechat API that would be better suited for this type of information exchange?
ear-dev commentedon Nov 14, 2022
@csmith14 I'm not sure why it's an anit-pattern? It seems to me that passing it in as a message custom field makes sense, because, just like disable input, we're sending a directive to the widget to perform an action and change state. fwiw...
csmith14 commentedon Nov 14, 2022
I'm not claiming that it is an anti-pattern, just asking the question. If that's what we want to do, though, I'll implement it.
It does still leave the question of how to communicate in the opposite direction, though, going from the widget -> DF app
ear-dev commentedon Nov 14, 2022
Right.... I was thinking that if we can just go back to the original tab (the one where the CX conversation started) then maybe we can pass a 'silent' message back to DF which will resume the conversation. Maybe if we configure the widget to respond to the response from the Ciao.webApp, after authentication complete, by just closing its current tab, then the original tab will by default come into focus again?
ear-dev commentedon Nov 14, 2022
@Shailesh351 @bhardwajaditya can you suggest which mechanism @csmith14 can use to send a message from the widget, into an open conversation with the DF.app?
The full workflow is this:
thanks.
bhardwajaditya commentedon Nov 14, 2022
We can use a new authentication successful system message, which can contain the authentication token as a custom field.
Based on the token validation in the DF app we can verify whether to resume or end the conversation there. The room would still need some custom field to indicate that this room can only proceed post authentication
csmith14 commentedon Nov 15, 2022
Summary of my conversation with @bhardwajaditya
We will implement a new API endpoint in RC server to receive roomId, token. This endpoint will be called from the Okta component once data is received back from ciao/iframe.
This endpoint will then update the room custom fields, which will be used to unmount/de-render the Okta component, and will pass the token to the DF app.
Shailesh351 commentedon Nov 16, 2022
@csmith14 @bhardwajaditya Do we get the JSON payload in the widget from the ciao web app? If yes why don't we set room customField from the widget itself instead of using a new API endpoint?
bhardwajaditya commentedon Nov 16, 2022
@Shailesh351 with room custom fields, we would have to develop an observer sort of mechanism, observers take more resources.
Basically we need something from client side to alert DF bot to proceed with next actions
ear-dev commentedon Dec 6, 2022
@csmith14 will package his current work in several PRs. Two will be ready for review, updates and test, and one still needs work. Please document the state of the work in both the actual PRs as needed, and a summary here. Thanks.
csmith14 commentedon Dec 8, 2022
Here are the three PRs representing current state of the project: