Improving sessions logic and start conversation button

[fabclj]

Success criteria

• This PR improves the behavior of the Start Conversation buttons, in Home Screen. The goal is to prevent the creation of new session on every button click. If a session is already active, it opens to that session.
• It was refactored the logic regarding the socket connection, in case of Home Screen active.
• We now connect to the socket only if the user hit the Start Conversation button from home or from teaser messages or from Previous conversation.
• It fixes a bug where Conversation starters button in Home Page and Teaser message, in case are disabled and some button is configured, it displays anyway on UI.

How to test

Test a new endpoint with all different configurations, with and without persistent userId / sessionId

1. Basic config without Home Screen, Privacy Screen or teaser message.
2. Config with Homepage active and/or Privacy Screen active
3. With action button in Home screen and/or in Teaser message and preview messages

[sushmi21]

I see conversation starters in teaser message, if conversation starters are disabled but the starter buttons are configured.

[sushmi21]

I am confused on what configuration should have prio (the settings in index.html or the settings from endpoint editor?).

• If I disable conversation starters in index.html and enable them in endpoint settings, the starter buttons are enabled.
• If I have one button configured in index.html (Button 1) and two buttons configured in endpoint settings (Button A, Button B) then in the UI I see Button 1, Button B

[sushmi21]

when I come to home screen from the middle of a conversation, I could still click the starter button in home screen and continue the current conversation.

[fabclj]

when I come to home screen from the middle of a conversation, I could still click the starter button in home screen and continue the current conversation.

Probably the best behavior in this case is to always create a new session/conversation when hit the starters buttons form Homescreen. I will ask the PO for confirmation.

[fabclj]

I am confused on what configuration should have prio (the settings in index.html or the settings from endpoint editor?).

• If I disable conversation starters in index.html and enable them in endpoint settings, the starter buttons are enabled.
• If I have one button configured in index.html (Button 1) and two buttons configured in endpoint settings (Button A, Button B) then in the UI I see Button 1, Button B

These issues about Conversation starters are unrelated to the sessions, but I agree on fix in this PR, as I did for the Homescreen starters.
I will ask our PO about this kind of priority, for sure we need to fix that.

EDIT: I had a look on our reducers and I realized we are doing a deep merge in this case.

Webchat/src/webchat/store/config/config-reducer.ts

Line 240 in ecfc550

const mergedSettings = merge({}, state.settings, action.config.settings)

In order to fix that, before to perform a deep merge, we should first parse the two objects and if the buttons are disabled, we make the array empty. Also, we need to define a priority in case both are enabled and include the buttons from the prio object only.
I believe this is something should be handled in a specific PR and discuss with PO.

[kwinto]

lgtm

[kwinto]

I am confused on what configuration should have prio (the settings in index.html or the settings from endpoint editor?).

• If I disable conversation starters in index.html and enable them in endpoint settings, the starter buttons are enabled.
• If I have one button configured in index.html (Button 1) and two buttons configured in endpoint settings (Button A, Button B) then in the UI I see Button 1, Button B

These issues about Conversation starters are unrelated to the sessions, but I agree on fix in this PR, as I did for the Homescreen starters. I will ask our PO about this kind of priority, for sure we need to fix that.

EDIT: I had a look on our reducers and I realized we are doing a deep merge in this case.

Webchat/src/webchat/store/config/config-reducer.ts

Line 240 in ecfc550

const mergedSettings = merge({}, state.settings, action.config.settings)

In order to fix that, before to perform a deep merge, we should first parse the two objects and if the buttons are disabled, we make the array empty. Also, we need to define a priority in case both are enabled and include the buttons from the prio object only. I believe this is something should be handled in a specific PR and discuss with PO.

I would not fix this in this PR though, as is out-of-scope. Maybe we can track this, and fix it later.