[jira] [Commented] (NIFI-12331) Introduce a PublishSlack processor

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-12331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793432#comment-17793432 ] 

ASF subversion and git services commented on NIFI-12331:
--------------------------------------------------------

Commit a21993ef7296113b78697a3fffa8527e343a6583 in nifi's branch refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=a21993ef72 ]

NIFI-12331 Added PublishSlack Processor

- Removed deprecated PutSlack and PostSlack

This closes #8120

Signed-off-by: David Handermann <ex...@apache.org>


> Introduce a PublishSlack processor
> ----------------------------------
>
>                 Key: NIFI-12331
>                 URL: https://issues.apache.org/jira/browse/NIFI-12331
>             Project: Apache NiFi
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Mark Payne
>            Assignee: Mark Payne
>            Priority: Major
>          Time Spent: 3h
>  Remaining Estimate: 0h
>
> The Slack API provides multiple different ways to publish messages to a Slack channel. NiFi already has two Processors for pushing to Slack - PostSlack and PutSlack. These processors have slightly different nuances, and the documentation does not articulate when to which one. One of them is oriented more toward sending FlowFile contents as an attachment while the other is oriented toward posting a message based on a property value. We should consolidate both of these Processors into a single Processor that is capable of sending a message and optionally providing the FlowFile content as an attachment.
> Both PostSlack and PutSlack make use of WebHooks instead of using the official Slack SDK. This means that rather than simply specifying the name of the Channel to post to, in order to send a message in Slack, the creator of the Slack App must explicitly add a Webhook for the desired channel, and the Processor must then be configured to use that Webhook. As a result, the channel cannot be easily configured and cannot be dynamic. This makes it difficult to use in conjunction with ListenSlack / ConsumeSlack in order to respond in threads.
> We need to consolidate both into a single Processor that is configured and behaves differently, based on the SDK.
> This Processor should be configured with properties that allow specifying:
>  * Bot Token
>  * Name of the channel to send to
>  * How to obtain the message content (FlowFile Content or specified as a Property that accepts Expression Language)
>  * If using a Property value, should be configured also with the message to send, and whether or not to attach the FlowFile content as an attachment to the message.
>  * Thread Timestamp (optional to convey which thread the message should be sent to) - should support Expression Language



--
This message was sent by Atlassian Jira
(v8.20.10#820010)