Add back support for Slack attachments

[paulhammond]

This pull request reimplements slack attachment support in Hubot.

It does so using an as-yet undocumented Slack API, where chat.postMessage will now accept an as_user boolean argument. Even though this API has been deployed to our production servers, it should be considered provisional and the details may change. We'll be documenting it on api.slack.com and confirm here when we're confident that the design is right.

I believe this is compatible with both scripts that used hubot-slack v2's attachment support, and scripts that use @inkel's hubot-slack-attachment script. But, I don't have many test cases, so I may have missed something.

I'm looking for feedback on whether this approach makes sense, and bug reports where the attachment support doesn't work with existing scripts.

[paulhammond]

I should add, this relies on slackapi/node-slack-sdk#15 being merged before it will work...

[evansolomon]

Should this be an object instead of an array? Below msg.attachments is set, which actually does work as "expected" even though it's an array (because arrays are objects) but it is pretty unusual.

[inkel]

API aren't explicitly clear on the format, but everything suggest that an object is needed, so I think @evansolomon is right.

[paulhammond]

Yep! Thanks for pointing this out, it's fixed in 471e71d

[lilyball]

I'm not entirely clear on what as_user is actually doing here.

[lilyball]

You don't seem to actually be adding data.username to the msg here. Surely that's necessary or it won't know what name to post as.

[inkel]

Unless it's getting the user name from the authentication token, which might make sense, but explicitly setting the username makes even more sense, IMO.

[paulhammond]

as_user causes the message to get the name from the authentication token.

This is because behind the scenes as_user causes the message to be sent as a standard message instead of a bot_message, which means the message is correctly attributed (among many other things).

[inkel]

@paulhammond this is really good news, that attachments support is enabled back in the main library. My only concern is relying on an undocumented feature.

[podviaznikov]

would love to see it merged into master

[omega]

A general feedback, based on how we used slack attachments in hubot in the old version is that we changed the adapter send method to treat strings and objects differently. Objects would be sent trough to customMessage, and treated as attachments. This allowed us to have our scripts send attachments for slack, and HTML messages for xmpp. It might not be everyones cup of tea, but something like that really made it easier for us to write scripts working with multiple adapters.

(related note is that our internal scripts often reply with an object that will return different representation for different adapters)

[inkel]

@paulhammond 🙌

Does this mean that hubot-slack-attachment can be deprecated or are is it still compatible?

Either way, this is great news 😺

[scott2449]

@inkel @paulhammond is there a way to set fallback? When I have notifications set the message is "NO FALLBACK DEFINED" no matter what I add to the payload.

[inkel]

@scott2449 could you paste a code snippet of the payload you're using? I could use that to check how am I doing it in hubot-slack-attachment. Thanks!

[scott2449]

I tried what you said in the docs and set fallback as such, maybe it's not carried to the PR:

robot.emit 'slack-attachment',
              channel: room
              fallback: "*#{issue}* _(#{url})_\nstatus: #{item.fromString} -> #{item.toString}"
              content:
                color: "d96b38",
                fields: [{
                    title: "Status Change",
                    value: "#{item.fromString} -> #{item.toString}"
                }]

[scott2449]

also tried setting message

[scott2449]

NM I had it outside of content

[inkel]

👍