Add messageBack support

[compulim]

Background

It will support:

• displayText (optional string for text to display on transcript)
• image (optional image for the button)
• text (optional string to send back to the bot, invisible to the user by default)
• title (optional string for the text of the button)
• value (optional JSON to send back to the bot, invisible to the user)

The user can specify both text and value, although they are mostly duplicated in nature (one as a string, another as a JSON object).

Although all properties are optional, we have a fallback rule if property is missing:

• title will fallback to displayText if it is missing

In the meanwhile, we are not deprecating imBack or postBack. All 3 card actions are supported and there is no plan to add a deprecation warning.

Investigations

• Adaptive Card: how other channels behave? Do they still use postBack or moved to messageBack?
• Do we need a UI to tell the user what they actually sent (text vs. displayText)?
  • Should we tell the user about the actual text property?
  • How about preserve history story?
    • If displayText is not sent to the bot, we might lose it when history is restored.
    • It could be a Web Chat specific feature, i.e. store it in channel data.
  • Answer: No, we don't need to tell the user what is actually sent.
• How to surface retry logic if the messageback activity failed without text/displayText?
  • Post back is broken today, but I want to make sure messageback don't break again.
  • If you have no clues on this, I can run it thru our UX designers.
  • Answer: For visible response, use the standard "send retry" status. For invisible response, modify the button to let the user to retry clicking on it.

To-do

• Implement in suggested actions
• Need investigation: Implement in Adaptive Card (card actions)
• Talk to Adaptive Cards team to see if they can help on the UX for "retry postback"
  • If a user click on a button on Adaptive Card and is failed to send, we should try to surface the error to that button [Edit] - diverting this one to Story: how to retry when postback failed? #1119 since @DesignPolice is working on it

[compulim]

@bwamie this is the work item for messageBack.

[dandriscoll]

Why is value dropped?

[compulim]

@dandriscoll When I talk to @bwamie, he said messageBack will only have two properties: text and title. Direct Line service do accept value property, but it may drop the actual content.

[compulim]

@bwamie do you know how other channels works with form submissions on Adaptive Cards?

[compulim]

Updated the bug description to capture our offline meeting.

[tomlm]

It should match the semantics described in the spec
https://docs.microsoft.com/en-us/azure/bot-service/bot-service-activity-spec?view=azure-bot-service-4.0

Message Back
A messageBack action represents a text response to be sent via the chat system. Message Back uses the following fields:

• type ("messageBack")
• title
• image
• text
• displayText
• value (of any type)

R7350: Senders SHOULD NOT include value fields of primitive types (e.g. string, int). value fields SHOULD be complex types or omitted.
R7351: Channels MAY reject or drop value fields not of complex type.
R7352: When activated, channels MUST send an activity of type message to all relevant recipients.
R7353: If the channel supports storing and transmitting text, the contents of the text field of the action MUST be preserved and transmitted in the text field of the generated message activity.
R7352: If the channel supports storing and transmitting additional programmatic values, the contents of the value field MUST be preserved and transmitted in the value field of the generated message activity.
R7353: If the channel supports preserving a different value in the chat feed than is sent to bots, it MUST include the displayText field in the chat history.
R7354: If the channel does not support R7353 but does support recording text within the chat feed, it MUST include the text field in the chat history.

[compulim]

@tomlm Few questions:

Updated with answers

Will tick the item when they are answered.

• There are multiple R7532/R7535, and which one is R7534 referring to?
  • Answer: Will fix.
• R7532: Is it a typo? "an activity of type messageBack" or "an activity of type message"?
  • Answer: Not a typo. imBack and postBack is an activity of type message.

And still few open questions, copied from "Investigations" section from the top and cleaned up a bit.

• Adaptive Card: how other channels behave? Do they still use postBack or moved to messageBack?
• Do we need a UI to tell the user what they actually sent (text vs. displayText)?
  • Should we tell the user about the actual text property?
  • How about preserve history story?
    • If displayText is not sent to the bot, we might lose it when history is restored.
    • It could be a Web Chat specific feature, i.e. store it in channel data.
  • Answer: No, we don't need to tell the user what is actually sent.
• How to surface retry logic if the messageback activity failed without text/displayText?
  • Post back is broken today, but I want to make sure messageback don't break again.
  • If you have no clues on this, I can run it thru our UX designers.
  • Answer: For visible response, use the standard "send retry" status. For invisible response, modify the button to let the user to retry clicking on it.

[dandriscoll]

The spec link is old :-(

I'll fix the numbering bug.

[v-kydela]

@compulim
@corinagum

It looks like messageBack displayText is strangely only supported with suggested actions and not hero cards. Can this issue be reopened?

[marcasmar94]

Any updates/workaround for making messageBack works on HeroCard/Adaptive cards buttons ?
Thank you

[sharatssj4]

Any updates on making messageBack work on HeroCards?

[compulim]

@v-kydela can you file a new issue? This issue is closed because the messageBack is (mostly) implemented.

In the new issue, can you put a sample hero card JSON? And link it to this bug so @marcasmar94 and @sharatssj4 can vote on that bug to make it more prominent.

[v-kydela]

@compulim - It seems to have been fixed after I left my last comment. I don't know where that work was tracked.