We're promoting problem checks to first class citizens in core. This migrates the problem check to the new API.
In the process of adding tests for this check, I discovered what seems like a mistake that likely means this check never worked until now. (See inline comment.)
Previously we were using the `ts` of the previous message we sent to the thread. While this did work under some situations, it's not recommended in the Slack API docs, and can lead to some unexpected behavior (e.g. when one of the threaded messages is deleted).
This commit updates our logic to always use Slack's returned `thread_ts`, which represents the thread's parent.
This patch concerns the Telegram integration. Currently, we always try
to process commands when we receive a hook from Telegram. To do so we
rely on the `text` parameters from a Telegram message but the
API documentation tells us this parameters is actually optional. It
means sometimes it’s not present in the payload we receive but we still
try to access it resulting in a crash.
This patch addresses the issue by simply returning early from the
`#process_command` method when `text` is missing from the payload since
we don’t have anything to process then.
This commit centralizes 'display name' generation into a helper, and updates it to respect core preferences for `enable_names` and `prioritize_username_in_ux`.
We were using the internal UID of the channel in the hint, which would then fail to match any 'channel' configs in Discourse (which use the human-friendly `#channel` format). This was causing automatic threading for transcripts to fail.
This allows for the discourse automation plugin to have a "Send Slack
Message" script.
The script fields are a message, url, and slack channel. This will allow
for a custom slack message to be posted but can link back to an
arbitrary url (hopefully a discourse url) like a list of unanswered
topics instead of strictly only allowing a slack message that links back
to a Discourse Post object.
When notifications about a topic are posted to multiple slack channels, and the Discourse channels are configured to "thread" the notifications, each channel will have a different thread_id. Previously we were only storing a single slack thread id per Discourse topic. This commit fixes that logic, so that threads in different channels are tracked separately.