Add Adaptive Card message format support
#157
Comments
Maybe not. Attempting to use this results in this error:
I've seen multiple references to a requirement that the card is wrapped as an "attachment". This appears to work: {
"type": "message",
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"contentUrl": null,
"content": {
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.2",
"body": [
{
"type": "TextBlock",
"text": "Hi <at>John Doe</at>"
}
],
"msteams": {
"entities": [
{
"type": "mention",
"text": "<at>John Doe</at>",
"mentioned": {
"id": "29:123124124124",
"name": "John Doe"
}
}
]
}
}
}
]
}but places the text within a "box":
|
After comparing against earlier test messages, this looks to be normal; I'm likely just not used to seeing a minimal implementation like we're starting with here. |
|
Looks like version 1.3 of the Adaptive Card format is the highest version supported (at present) by Microsoft Teams for user generated messages. |
|
Learned that multiple cards in the attachments collection without carousel display option hides cards after the first. Not sure if this is a bug, or if it's intentional. |
Inconclusive. Per https://docs.microsoft.com/en-us/microsoftteams/platform/task-modules-and-cards/cards/cards-reference, Adaptive Card schema v1.4 or earlier is supported if the card is sent via bot or action based messaging extension. It's unclear where incoming webhooks fall. |
Using https://adaptivecards.io/designer and setting
Looks like 1.3 might be the max supported version after all. |
|
Setting
|
FWIW: Setting the version to 1.5 in the JSON payload isn't enough to cause the remote API to reject it. Not something to rely on, but worth noting. |
|
Some definite drawbacks of using an Adaptive Card vs the legacy MessageCard, formatting in particular:
The last two I personally relied upon when pushing formatted log messages or error messages from monitoring systems into Teams channels. Will need to annotate the formatting functionality sufficiently to indicate that it's intended for use with MessageCard text and not text intended for Adaptive Cards. |
|
Beginning initial polish phase. |
Ended up "moving" the functionality into the |
Add early (and incomplete) implementation of `Adaptive Card` format (new `adaptivecard` package). This new package is an alternative to the current implementation of the legacy `MessageCard` format (`messagecard` package). Remove `botapi` package. This package was a partial implementation and intended as a temporary resource until the `adaptivecard` package was developed sufficiently to replace it. This package could make an appearance later in a more complete form if there is need for it. CHANGES The changes listed here are in comparison to the previous v2.7.0-alpha.1 release. - add initial implementation of the `adaptivecard` package - remove partial implementation of `botapi` package - incomplete implementation, known issues (atc0005/send2teams#225) - example code - create subdir for new `adaptivecard` examples and populate with equivalents - create subdir for existing `messagecard` examples - refresh doc comments of existing examples - attempt to simplify implementation of examples - documentation refresh - cover new features provided by the new `adaptivecard` package - make note of plans to extend v2 branch features while retaining backwards compatibility with an eye towards a future v3 series - add `goteamsnotify.InList()` helper func - simplify `goteamsnotify.messagePreparer` interface - simplify `MessageCard.Prepare()` implementation - explicitly mark files containing exclusively deprecated code - explicitly mark existing formatting functionality as specific to the `MessageCard` format LIMITATIONS - the `adaptivecard` package is new and its API is subject to change before the next stable release - the `adaptivecard` package is incomplete - while the new package contains sufficient functionality to be useful and provide a close approximation of functionality to the existing `messagecard` package, it is still missing support for some (available) features that the older package provides - there are many TODO items for the new `adaptivecard` package, most of which are intended to be removed before the next stable release - there are active `gocognit` linter warnings for the `Validate()` method for multiple types in the new `adaptivecard` package - this method is responsible for asserting known requirements for multiple field values for its type - more "bake time" is needed to determine a simpler approach REFERENCES - refs GH-157 - refs atc0005/send2teams#225
|
GH-162 adds the first usable implementation of the new package. Unstable/dev release v2.7.0-alpha.2 provides that functionality for general review & feedback. This should resolve atc0005/send2teams#225 and provide a starting point for GH-127. |
|
I've closed GH-127 and marked it as resolved (no negative feedback received since I noted the new support two months back). I plan to focus on linting errors surfaced from recent PRs, then tag a release candidate shortly after. |
Create internal validation helper and use it to replace existing validation logic used in methods identified by gocognit. The end result is that the larger, more complex validation methods are (hopefully) more concise and readable now. I began the process of replacing the logic used by other validation methods with validation helper calls, but have not finished the conversion work. I plan to return to this with a future PR once I've reviewed the remaining (unconverted) validation logic further. Credit to Fabrizio Milo for sharing the original implementation: - https://stackoverflow.com/a/23960293/903870 - https://github.com/Mistobaan refs GH-157
Output from the most recent PR submitted by dependabot: |
Create internal validation helper and use it to replace existing validation logic used in methods identified by gocognit. The end result is that the larger, more complex validation methods are (hopefully) more concise and readable now. I began the process of replacing the logic used by other validation methods with validation helper calls, but have not finished the conversion work. I plan to return to this with a future PR once I've reviewed the remaining (unconverted) validation logic further. Credit to Fabrizio Milo for sharing the original implementation: - https://stackoverflow.com/a/23960293/903870 - https://github.com/Mistobaan refs GH-157
- rename `validation` package back to original name of
`validator`
- attempting to follow the guideline of naming a package
based on what it provides, not what it does
- drop "Must" prefix from validation methods in an effort to make the
method names sound more natural
- add Validator.NoNilValuesInCollection method
- add validation handling for ColumnItems type alias ([]*Element)
- use Validator methods for validation of Column type
Further refactoring could be beneficial, as would further conversion
of Validate method implementations to use of the validator package.
refs GH-157
- rename `validation` package back to original name of
`validator`
- attempting to follow the guideline of naming a package
based on what it provides, not what it does
- drop "Must" prefix from validation methods in an effort to make the
method names sound more natural
- add Validator.NoNilValuesInCollection method
- add validation handling for ColumnItems type alias ([]*Element)
- use Validator methods for validation of Column type
Further refactoring could be beneficial, as would further conversion
of Validate method implementations to use of the validator package.
refs GH-157
|
Initial implementation complete. Further polishing is needed, but will focus on that in the next release. |
I've not fully explored it, but as part of the initial work for GH-127 I learned that it appears to support both user mentions and existing functionality provided by the legacy
MessageCardformat.Initial support for this format would unify the functionality currently provided (separately) by the
messagecardandbotapipackages.The text was updated successfully, but these errors were encountered: