Message Behaviour Changed from 3.10 on

[watter]

Message appearance changed from version 3.10 on

Using the API to send some test messages I've found that the message behaviour changed from 3.10 on (3.11 and 3.12 and 3.12.1 act the same way).

On 3.10 we had the following

As 3.11 and up we've got the following result:

Steps to reproduce:

1. Send an API call:
   I've used the following curl command at file
   envia-msg-rc.txt

in short, the curl call below does the "magic":
`
curl -s -H "X-Auth-Token: $AUTHTOKEN"
-H "X-User-Id: $USERID"
-H "Content-type:application/json"
${SERVER}/api/v1/chat.postMessage
-d "{
"alias": "Gruggy",
"avatar": "http://res.guggy.com/logo_128.png\",
"channel": "#${CHANNEL}",
"emoji": ":smirk:",
"text": "Sample message",
"attachments": [
{
"audio_url": "http://www.w3schools.com/tags/horse.mp3",
"author_icon": "https://avatars.githubusercontent.com/u/850391?v=3",
"author_link": "https://rocket.chat/",
"author_name": "Bradley Hilton",
"collapsed": false,
"color": "#ff0000",
"fields": [
{
"short": true,
"title": "Test",
"value": "Testing out something or other"
},
{
"short": true,
"title": "Another Test",
"value": "Link something and this and that."
}
],
"image_url": "https://www.confianca.com.br/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/1/1/114520-7.jpg.jpg",
"message_link": "https://google.com",
"text": "Yay for Manga!",
"thumb_url": "http://individual.icons-land.com/IconsPreview/3D-Food/PNG/128x128/Berry_Strawberry.png",
"title": "Attachment Example",
"title_link": "https://www.youtube.com/watch?v=9i_9hse_Y08",
"title_link_download": true,
"ts": "2020-12-09T16:53:06.761Z",
"video_url": "http://www.w3schools.com/tags/movie.mp4"
}
]
}" | jq '.'

`

Expected behavior:

I expect that the message still displays the same way as it does in 3.10 and below

Actual behavior:

As 3.11 and up we've got the following result:

Server Setup Information:

• Version of Rocket.Chat Server: from 3.10 and up
• Operating System: Linux
• Deployment Method: docker

Client Setup Information

• Desktop App or Browser Version: Google Chrome 87.0.4280.88 (Versão oficial) 64 bits and other versions
• Operating System: Linux

Thanks in advance

LEslie

[HiveMindNet]

We have also seen this change.

[rahljoshi]

Can I work on this issue?

[AllAstronauts]

Bump on all of this. A lot of my integrations are broken now. attachment - text parses alright but that's about it. Losing audio_url right now hurts.

EDIT: I've routed around this for now, for audio file embeds at least, by altering the attachments - text to insert the audio controller directly.

"attachments": [ { "text": "<audio controls src='" + request.content.audio_url + "'></audio>", "audio_url": request.content.audio_url, "audio_type": "ogg", } ]

I'm just pushing out a title and the audio_url from my external source to the integration and recreating the message in the integration itself - you'll likely need to adjust this on your end but you get the idea. The "text" field will parse html. audio_type is there as I wasn't sure if the built-in audio attachment wasn't now requiring more vars to fire - that doesn't appear to be the case, and I'm leaving the actual audio_url line in there as well so I can catch when this gets patched (I'll start seeing two audio players then)

[MPritsch]

Links and formatting seems to not work in attachments. This breaks the gitlab-integration resulting in a message like this:

Usually you would be able to click the link and see who committed but the message is cut off now. We use rocket.chat 3.11.3

Edit: This could be an unrelated issue as we used 3.10.5 before without this issue. (or it was introduced with a minor version in 3.10.x)
Edit2: My issue could be related to this #20606 which should be fixed in 3.12

[hugodecasta]

Still having this issue in 3.13.1 !

[Gadiguibou]

Same issue here on 3.15.0, maybe even more problems... Our Alertmanager integration messages used to look like this:

And now look like this:

😞

[galiazzi]

Same problem in 3.18.1 version

[AllAstronauts]

Still a mess if not worse. The recent forced Markdown has actually broken all the previously working audio bits I cobbled into the text field (mentioned earlier in this issue) and I for the life of me cannot get audio players to fire at all no matter how I format or call out the audio url into the message. This has been one hell of a regression and I don't understand why it is getting so little traction. I'll take any suggestions...

EDIT: I really don't want to upload the files directly to the room/channel, there's really no need to duplicate the files at all, but I don't even think anyone on staff has even acknowledged this and I'm SOL on other options I think. I wonder if these parsers that have borked out have test cases they need to pass before push approval.

ANOTHER: I should note, the RC phone app displays the audio embeds fine (webhook or API called), it's only on the web that these audio bits don't parse. Also the Electron desktop app fails at displaying these correctly.

[AllAstronauts]

With the latest version of RC (Ubuntu Snap install), a tweaked version of my hack from last year of using the text var (this time using the initial text var, not the one within the attachments structure) and pushing a manually created html call works again - but ONLY for desktop browsers. It does not parse in the mobile app. Not ideal but that counts as working for 99.99% of my use needs for the moment. Note you do still need to include "something" in the attachments section - otherwise, at least in my case, it duplicated the audio insert (:shrug:). I'm about 45 days out from a drop-dead date with the affiliated org this chat belongs to so will probably disable Snap auto-updates to ensure this hack is working at that time.

Working for Webhook integration or an API call.

[OctavioSI]

So, I'm not sure if this is still relevant or not, but I was trying to attach to my message an audio_url and the error above (attachment not showing the embedded player) was driving me crazy.

My workaround this was to simply send a simple message with the audio_url in it, and the embedded player showed fine, like this:

{
   "message":{
      "rid":"mAzsEXALdjqqYPY99",
      "msg": "http://www.w3schools.com/tags/horse.mp3"
   }
}