Slack Block Kit support

[joarobles]

❓ Slack Block Kit support?

Is it possible to add Block Kit support for Slack notifications? I think that the notification body might be a JSON attribute instead of markdown text.

[caronc]

Interesting... i wonder if it could be more designed similar to how the MS Teams Templating section was done.

[joarobles]

I think so, but that would require to have the template located elsewhere and couldn't be easily integrated with the stateless API.

Maybe the body attribute could receive markdown or json based on a URL parameter (like bodyFormat in this example)?

{
	"urls": "slack://xoxb-asd123/%23general?bodyFormat=json",
	"body": [
		{
			"type": "section",
			"text": {
				"type": "plain_text",
				"text": "This is a plain text section block.",
				"emoji": true
			}
		}
        ]
}

So the body content would be directly set in:

apprise/apprise/plugins/NotifySlack.py

Line 384 in 1816c44

'blocks': [{

.

[joarobles]

Hi @caronc! Did you have the chance to take a look at this?
It would be very nice to have this feature to enrich Slack messages

[caronc]

Hi, i didn't forget, it's jsut so hard to prioritize all of the tickets open. I tend to do bugs first and super quick and easy enhancements first. 🙂

This request I think i'm still scratching my head on. Apprise is really meant to just be a quick and dirty message system. Not a fully featured (all bells and whistles for all end points). This is a grey area as blocks sure are feature rich. You definitely need to provide it a full JSON object. It steps away from the title body, and message type (warning, info, etc) style.

MS Teams kind of has a feature like this as well which crosses this line, but it's able to do it as a template. At the end of the day, the MS Teams object still only takes a body and title. But the template is as big as you want it to be with {{body}} references you can pass in the data to. The template to use is identified on the Apprise URL. So like:

• msteams/<credentials>?template=http://host/to/template.json&:target=Chris&:whence=this%20afternoon

the :target=Chris and :whence=value become additional variables you can pass into the template...:whence populates any {{whence}} entries you identified in your template. So that gives you more dynamic entries.

I don't quite agree with the idea of passing in a full JSON object because how would other services receive it; they'd just end up passing the JSON along. You end up defining a feature that ONLY works with one service (exclusively) and would look awful through all others.

Do you see where I'm coming from?

[operatorequals]

Hey, just started exploring this immense project and I can't but express my woah!
I find this impossibly good. Thank you for taking the time and effort to design this, implement it, and maintain it too, while keeping it free.

---

I came here for this exact feature. My approach would be exactly as what happens in MS Teams, with a JSON (or even YAML?) template of the Slack Blocks API, like:
template1.yaml:

{"blocks": [
      {
      "type": "section",
      "text": {
          "type": "mrkdwn",
          "text": "Test Apprise blocks"
      }
    }
  ]
}

referenced through the URL (or maybe from some parameter of notify() would be great too) using the template=/some/where/template1.json parameter.

I totally get that pushing some json.dumps(blocks_obj) in the body would totally mess things up if the URL of the object were to change, as it would deliver raw JSON to some other plugin, so I'd totally refrain from such design.

---

I'm wondering whether you are still looking into this and feeling like implementing it.

Thanks again for this!

[operatorequals]

Additionally, now that I have been skimming through the code, I don't see why we couldn't move the definition of templates one level up, to the NotifyBase, providing pre-templated messages to all plugins.

The ones that need special handling when a template is in use (such as posting the JSON in the Slack's case) can be implemented in each plugin independently.
In the same spirit, there is no need for the template to be of any format, it can just be parsed as Format Python string, and handle it as JSON (json.loads probably), only in plugins that need it.

This way, the blocks=yes parameter in Slack will still have meaning, as the template will be a textual one, if the blocks is not defined, and a JSON Blocks one, if it will.

What do you think?
(I'm sorry for the double post)

---

(Avoiding a triple post)

Hey @caronc

I submitted this PR addressing the above, in the way MSTeams does it.
I took the liberty of some decisions, such as that footer does not work when a template is used with blocks, to grant full control to the one creating the templates.

Let's discuss whether we need such thing and change the PR accordingly!

---

Hey @joarobles

This PR implements your comment above. It is less intrusive than the one above, with WAY less added code and respects already existing parameters.