[
https://issues.apache.org/jira/browse/NIFI-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860900#comment-17860900
]
Joe Witt commented on NIFI-13452:
---------------------------------
Right now I'm just trying to understand the use case.
When new components show up we need to really understand what they're for and
why they're beneficial to the community at large. To make a contribution of a
new feature/change/improvement it is really important to explain the why, who
it is for, how it will get maintained and a host of other things. Adding
things is a lot of work but so is the maintenance of it.
As a community historically we've not been as thoughtful about this as we
should but the push to 2.0 has been very eye opening in just how much technical
debt and user complexity we can reduce by doing a better job on this both as
contributors, and reviewers, and the community at large. We also can learn
from other communities that have done things well and in some cases much better
than we have (Kafka is a good example - so too is Airflow, and there are
probably others).
We cannot yet really discuss whether something is complicated or technically
doable until we've established the use case.
For this example the JIRA description reads
{noformat}
The goal of this JIRA is to create a new processor so it'd possible to be fetch
the emojis added to a message in Slack.
{noformat}
That writeup is not sufficient to help us determine how best this might be done
and surely leads to the question 'why not make sure reactions come out of
ConsumeSlack?'
>From the comments provided so far then in response to that question I think
>the intended use case is...
Users of NiFi can use ConsumeSlack or ListenSlack today to capture Slack
messages. These currently do not include reactions which are at times helpful
for a user to understand value of a given message. And importantly reactions
are only useful when understood in the context of an individual message. It
would be helpful then if we provided a mechanism whereby users could indicate
that certain messages are of interest, such as by their content or metadata,
that they'd like to capture the reactions for that message. Importantly
reactions might occur over a period of time.
A proposed solution then is determined by reading the PR
Provide a GetSlackReactions processor which looks at two required processor
properties which determine the channel identifier and message timestamp for
which to capture reactions. Then for a user configurable period of time will
wait for and gather reactions or it can optionally release messages as soon as
a single reaction is found for it. For each reaction found the name will be
stored as a flowfile attribute as will the count of that reaction type found.
---
What I expected to see was the processor would be configured to take as input
the flowfile that comes out of ConsumeSlack (or maybe ListenSlack) and that it
could then find the proper channel and timestamp identifier from the flowfile
attributes. But this is not what the code appears to do and the test shows it
is expecting the message timestamp and channel id do indeed come from the
processor config.
I do not think it is a valid use case in NiFi for users to supply a specific
processor property containing the channel ID and timestamp for a message.
> GetSlackReaction processor to fetch reactions
> ---------------------------------------------
>
> Key: NIFI-13452
> URL: https://issues.apache.org/jira/browse/NIFI-13452
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Zsihovszki Krisztina
> Assignee: Zsihovszki Krisztina
> Priority: Major
>
> The goal of this JIRA is to create a new processor so it'd possible to be
> fetch the emojis added to a message in Slack.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
