@chalasr next milestone is due by May 31, 2020 and Slack will not allow to generate a new token after May 5th, 2020, so this bridge will become unusable for newcomers.

What is the best approach for this?

Updated SlackTransport to use Incoming Webhooks Slack app for sending messages.

Tests fixed

I have removed the channel & username setup from DSN.
As specified here, you cannot override the default channel (chosen by the user who installed your app), username, or icon when you're using Incoming Webhooks to post messages.

@Nyholm can you have a look on this? #SymfonyLive :)

I'm taking over to finish this PR.

New usage:

use Symfony\Component\Notifier\Message\ChatMessage;
use Symfony\Component\EventDispatcher\EventDispatcher;
use Symfony\Component\Notifier\Transport;

$dispatcher = new EventDispatcher();

// https://hooks.slack.com/services/T64B39MPG//BABMSGW9C/ZOhzOOo726qazXhJVxRBs2yP
$slack = Transport::fromDsn('slack://default/T64B39MPG//BABMSGW9C/ZOhzOOo726qazXhJVxRBs2yP', $dispatcher);
$message = new ChatMessage('Hello!');

$slack->send($message);

// change the recipient
$options->recipient('T64B39MPG/BMNM4FUA1/98mBsq2VHu1r5gOWG3D2wUdK');
$slack->send($message);

Thank you @birkof.

Thank you too, @fabpot!

@birkof @fabpot, I don't understand the rationale behind using webhooks instead of the web API here.

Was it to avoid setting up a Slack app, and use to use the Incomning Webhooks app? But it is part of Slack's legacy custom integration.

So if we're left with having to create a Slack app anyway, why use webhooks over the web API?
Webhooks management is laborious when notification need to reach individuals, or even any small number of channels.

Would this mean a different transport?

@xavierbriand TBH, there is no reasons on my part. Diving into Slack docs is just too tedious and time consuming for me. So, I think I'm just trusting people willing to fix the mess :) If you think there is a better solution, please, tell us what that would be :)

@xavierbriand I think it is a misunderstood on your side, maybe because the title here.
This aims to replace legacy "Incoming Webhooks via web API" implementation with "Incoming Webhooks Slack app".

My confusion probably comes from the fact that 5.0 was implementing chat.postMessage and working as expected with current OAuth access tokens.

Have the notifier using Slack apps webhook is a totally valid case. I wonder what would be a way to us either or. Could that be express in the DSN and then the transporter could infer the expected intent?

From 5.0 and 5.1 implementations:

• webhook (current implementation) slack://default/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
• web api: slack://xoxp-...@default/?channel=...

Having a username could be the trigger to switch from one method to the other.
Or using a different scheme together (e.g. slack-api) with one factory and two transports?

@birkof tell me what you think, I'll submit a PR.

I understand. But I believe Slack was discontinuing that API. That is why we were forced to change things.

Im sorry if it caused any issues.

Feel free to open a new issue or discuss with the community in Slack. Let's not ping people in this thread anymore. =)

IMHO and how @Nyholm said, we shouldn't rely anymore on discontinued API.

Thank you for adding this! 🎉

I see no mention about this in the docs, however. It still refers to the old token authentication/setup.

I see no mention about this in the docs, however. It still refers to the old token authentication/setup.

It has been reverted to allow to send to different recipients instead of a single one which is pre-selected with a webhook.

Thanks! Yeah, I found the corresponding PR #37138. Wasn't sure about the reasons for this revert, but now I know :)