Simplify thread reaction and add thread_please for broadcast enforcement

[Copilot]

Based on investigation, Slack's API does not allow programmatically removing messages from the channel without also removing them from threads. This PR simplifies the approach and adds a dedicated reaction for handling broadcasted messages.

Changes

automator/lambda_function.py

• Reverted complex broadcast detection logic from handle_slack_post()
• Simplified to original behavior without broadcast handling

automator/config.yaml

• Changed "thread" reaction from using multiple handlers (types: [REMOVE_BROADCAST, SLACK_POST]) to single handler (type: SLACK_POST)
• Added new "thread_please" reaction with type: DELETE_MESSAGE that:
  • Deletes the broadcasted message completely
  • Sends DM to user explaining broadcast functionality is against community guidelines
  • Includes link to guidelines: https://datatalks.club/slack/guidelines.html#taking-part-in-discussions
  • Asks user to repost without using broadcast functionality

tests/test_automator_lambda.py

• Updated tests to verify "thread" reaction uses single handler
• Added test for "thread_please" reaction configuration
• Updated TestMultipleHandlers to verify single handler execution

Behavior

"thread" reaction

Simply posts a reminder message to use threads (no broadcast handling)

"thread_please" reaction (NEW)

When triggered on a broadcasted message:

• Deletes the message completely (cannot remove from channel only)
• Sends DM to user: "Please don't use the 'Also send to channel' (broadcast) functionality..."
• Provides guidelines link and asks to repost without broadcast

Testing

• ✅ All 22 tests pass
• ✅ Code review completed
• ✅ Security scan passed (0 issues)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Thread please deletes message</issue_title>
<issue_description>Expected behavior for thread please reaction:

• when triggered on the main message, writes a reply in the thread
• when triggered in the thread, adds a reply to the thread
• when triggered on a message that's broadcast to the channel, removes it from the channel but not from the thread, adds message to the thread

For the last scenario it doesn't work now. It deletes the message completely and sends the message to the main channel not thread </issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Thread please deletes message #11

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[alexeygrigorev]

@copilot so I did some investigation and turns out that there is no programmatic way to remove message from the channel without removing it from the threads. So what we will do is let's roll back functionality to I told what it was before a few if you commit before a few pull requests before so when I when we removed when we had two types for threat so when it was just one. Yeah let's keep that. So we should have no logic for dealing with two types for a message. So that's one thing. Another thing iscreate a new handler for thread_please which deletes the message and sends topic starter is. Please don't use the reply to channel functionality. This is against the community good guidelines. Send the links to the guidelines and say that feel free to repost this message again without using the broadcast functionality

[Copilot]

@copilot so I did some investigation and turns out that there is no programmatic way to remove message from the channel without removing it from the threads. So what we will do is let's roll back func...

Done! I've made the following changes in commit 8e87dd9:

1. ✅ Reverted the broadcast handling logic from handle_slack_post()
2. ✅ Changed "thread" reaction to use single handler (type: SLACK_POST)
3. ✅ Added new "thread_please" reaction that:
   • Deletes the message completely
   • Sends DM to user explaining broadcast functionality is against guidelines
   • Includes link to https://datatalks.club/slack/guidelines.html#taking-part-in-discussions
   • Asks user to repost without broadcast

All 22 tests pass and no security issues found.