Mattermost Integration icon_url

[cbrand]

Hi All,

Using Zammad 4.0 installed from package on Ubuntu 20.04. I’ve setup the Slack integration to our Mattermost Server v5.33.2. I’m using a mattermost incoming webhook created by my user account. Everything works good with the exception of the icon_url. I get a broken icon image. I’ve specified the same icon.png from the mattermost webhook and from the integration in Zammad.

this is what it looks like in mattermost.

Anyone using the slack integration to connect to mattermost seeing this or is it some configuration I’m missing?

Thanks

[tingeber]

I have the same issue, @cbrand (version 4.1.x on Debian 10)

I noticed that, no matter what I set as icon (both in Zammad and in Mattermost), the payload reference doesn’t change; it stays "icon_url":"https://zammad.com/assets/images/logo-200x200.png" and that URL is 404, which explains the “broken image” icon, because there is no image at that URL.

It seems like a noticeable bug for anyone using slack/mattermost integration so I tend to think it has something to do with my setup, but unsure what else to try.

[cbrand]

@tingeber Thanks for finding the payload reference! I hadn’t had time to look at the payload and see what it was actually trying to use for the icon.

Using that icon_url I was able to track down the file calling it.

grep -rnw '/opt/zammad/' -e 'logo-200x200.png'
/opt/zammad/app/models/transaction/slack.rb:164:      logo_url = 'https://zammad.com/assets/images/logo-200x200.png'

I edited the file and change the icon_url to the custom icon I was wanting to use for notifications in mattermost.

On line 164, I changed
logo_url = 'https://zammad.com/assets/images/logo-200x200.png'
to
logo_url = 'https://put_your_custom_icon_url_here.png'

restarted the zammad service and triggered a notification and it worked!

There is recent issue on the github page referencing the missing icon on the zammad website causing a 404 error.

Slack bot image url returns 404

I posted my fix there. it looks like the variable for the icon_url isn’t being set somewhere along the line and defaults to the hardcoded icon_url instead.

This is a temporary fix, and will have to be done after each update, but perhaps it will get fixed soon.

best regards