argoproj / argoproj/notifications-engine
Support Slack message updates and replies by ts
- Dominant language
- Go
- Stars
- 334
- Forks
- 217
- PR merge metrics
- No merged PRs in 30d
Description
It would be useful for the Slack integration to directly support
* the [`thread_ts` option](https://api.slack.com/methods/chat.postMessage#arg_thread_ts) when posting a message, and
* the [`ts` argument](https://api.slack.com/methods/chat.update#arg_ts) for updating a message.
This would allow notifications to reply to specific threads and update specific messages.
For example, supplying `slack.thread_ts` would respond to the Slack message by including it in the payload of [chat.postMessage](https://api.slack.com/methods/chat.postMessage):
```yaml
template.app-sync-status: |
message: |
This is a reply to a thread
slack:
threadTs: "12345678.1234567"
```
And supplying `slack.update_ts` would update a Slack message by instigating a [chat.update](https://api.slack.com/methods/chat.update) request and including its value in the `ts` option:
```yaml
template.app-sync-status: |
message: |
This is an updated message
slack:
updateTs: "12345678.1234567"
```
`threadTs` and `updateTs` would both be optional, and mutually exclusive.
`threadTs` and the existing `groupingKey` would be mutually exclusive.
Non-BC-breaking.
I am not familiar with Go so I probably won't be able to implement this myself, but I'm hoping this enhancement gets support from contributors.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the Slack integration's handling of chat.postMessage and the existing groupingKey behavior, then compare the request shapes with Slack's thread_ts and ts arguments. Confirm how configuration maps camelCase fields such as threadTs and updateTs. Done means optional thread replies and message updates work, the stated mutual exclusions are enforced, and existing grouping behavior remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100