Allow passing optional arguments to chat.postMessage

[knkarthik]

Description

chat.postMessage has several useful optional arguments. Please support them! Personally I'm interested in unfurl_links and unfurl_media so that I can turn the auto-unfurl off for my use-case. Right now I've to roll my own version of this or use other actions that supports passing there arguments.

What type of issue is this? (place an x in one of the [ ])

• [ ] bug
• [x] enhancement (feature request)
• [ ] question
• [ ] documentation related
• [ ] example code related
• [ ] testing related
• [ ] discussion

Requirements (place an x in each of the [ ])

• [ ] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [ ] I've read and agree to the Code of Conduct.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

package version:

node version:

OS version(s):

Steps to reproduce:

Expected result:

What you expected to happen

Actual result:

What actually happened

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.

[misscoded]

Hi @knkarthik! Certainly a reasonable request. We've labeled this as a good first issue for the community (so feel free to tackle this yourself), else we'll see if we can find time after the holiday break to introduce it. 🙂

[laimonasA]

Hi, I've just had a look at this with an intention of implementing it, but there's no need!

@knkarthik you can pass optional arguments as part of the payload or payload-file-path arguments for example:

Using payload:

...
uses: slackapi/[email protected]
with:
  payload: |
    {
      "unfurl_links": true,
      "unfurl_media": true
    }
...

Using payload-file-path:

...
uses: slackapi/[email protected]
with:
  payload-file-path: './path-to-payload-file.json'
...

Where the payload file (./path-to-payload-file.json) would look like:

{
  "unfurl_links": true,
  "unfurl_media": true
}

---

This is possible because the payload object is actually spread to the postMessage and update functions.

I haven't spent any time looking into what would happen if you passed in invalid options to these functions, I assume the web function call would return an error, but I'm not sure how this workflow/action would handle it. So it might be worth checking that the correct error is shown and not masked by a generic "payload" error.

In any case, I think instead of implementing this feature, it would be worth updating the documentation to say that optional arguments can be passed in, how it is possible, and an example to demonstrate it.

[knkarthik]

@laimonasA Thanks for investigating this! Just to confirm, would this also work if the payload uses block kit? Something like:

      {
        "unfurl_links": true,
        "unfurl_media": true,
        "text": "GitHub Action build result: ${{ job.status }}\n${{ github.event.pull_request.html_url || github.event.head_commit.url }}",
        "blocks": [
          {
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "GitHub Action build result: ${{ job.status }}\n${{ github.event.pull_request.html_url || github.event.head_commit.url }}"
            }
          }
        ]
      }

[laimonasA]

@knkarthik Yes, I've got something similar and it works for me

[pashcan]

@laimonasA, suppressing unfurling does not appear to work for me while using Slack Workflow Builder & Webhook.

...
uses: slackapi/[email protected]
with:
  payload: |
    {
      "pr-url": "https://github.com/some-org-here/test-slack-action/pull/4",
      "version": "0.4.3",
      "unfurl_links": false,
      "unfurl_media": false
    }
env:
  SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
...

I tried with "unfurl_links": "false", tried both with and without unfurl_links variable in the Slack workflow.

The only time Slack does not unfurl the URL is when it is the same as the one I just sent.

Any suggestions?

[laimonasA]

Apologies @pashcan but I'm not sure how Slack Workflow Builder works in this situation, inspecting the code for this workflow it looks like the payload should be getting sent as expected.

Having a quick look at this: https://api.slack.com/reference/messaging/link-unfurling

I would be looking in the configuration for the app (or permissions), and I don't think the unfurl variables need to be included in the payload of your workflow.

I hope that helps

[pashcan]

After some additional poking around, I discovered that our slack workflows were of the unmigrated legacy kind. Config to suppress unfurling works with the new workflow! :tada:

Knowing that it should be possible gave me the determination to continue looking. Thank you @laimonasA :pray:

PS: For anyone else stumbling onto this before the legacy workflows are fully deprecated in Sept 2024, the easy way to tell which one you have is by looking at your webhook URL: legacy ones use hooks.slack.com/workflows and the new workflows use hooks.slack.com/triggers.