Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/zerver/webhooks/slack_incoming/tests.py

388 lines
11 KiB
Python
Raw Normal View History

mypy: Enable new error explicit-override. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-10-12 19:43:45 +02:00
from typing_extensions import override
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
from zerver.lib.test_classes import WebhookTestCase
class SlackIncomingHookTests(WebhookTestCase):
webhooks: Rename STREAM_NAME to CHANNEL_NAME in tests.
2024-05-04 22:02:50 +02:00
CHANNEL_NAME = "slack_incoming"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
URL_TEMPLATE = "/api/v1/external/slack_incoming?&api_key={api_key}&stream={stream}"
webhook: Rename FIXTURE_DIR_NAME to WEBHOOK_DIR_NAME. Since FIXTURE_DIR_NAME is the name of the folder that contains the view and tests modules of the webhook and another folder called "fixtures" that store the fixtures, it is more appropriate to call it WEBHOOK_DIR_NAME, especially when we want to refer to the view module using this variable.
2021-06-26 09:18:33 +02:00
WEBHOOK_DIR_NAME = "slack_incoming"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
def test_message(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message = """
Hello, world.
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
"text",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
expected_message,
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
)
slack_incoming: Fix formatting fixups with overlaps, or at start/end. The previous regular expression required a `[^\w]` at the start and end of the match. This had two unintended effects -- it meant that it could never match at the start or end of a string, and it meant that *adjacent* words required *two* non-word characters between them, as the pattern matches cannot overlap. Switch to allowing string start/end to anchor the matches, and make the trailing `[^\w]` be a zero-width look-ahead, to allow the patterns to overlap. Also remove the spurious `^` within the inner character classes, which prevented `*foo^bar*` from matching. Finally, add tests to cover the functionality, which was previously untested.
2022-11-29 22:10:34 +01:00
def test_message_formatting(self) -> None:
tests = [
("some *foo* word", "some **foo** word"),
("*foo*", "**foo**"),
("*foo* *bar*", "**foo** **bar**"),
("*foo*a*bar*", "*foo*a*bar*"),
("some _foo_ word", "some *foo* word"),
]
webhooks: Rename STREAM_NAME to CHANNEL_NAME in tests.
2024-05-04 22:02:50 +02:00
self.subscribe(self.test_user, self.CHANNEL_NAME)
slack_incoming: Fix formatting fixups with overlaps, or at start/end. The previous regular expression required a `[^\w]` at the start and end of the match. This had two unintended effects -- it meant that it could never match at the start or end of a string, and it meant that *adjacent* words required *two* non-word characters between them, as the pattern matches cannot overlap. Switch to allowing string start/end to anchor the matches, and make the trailing `[^\w]` be a zero-width look-ahead, to allow the patterns to overlap. Also remove the spurious `^` within the inner character classes, which prevented `*foo^bar*` from matching. Finally, add tests to cover the functionality, which was previously untested.
2022-11-29 22:10:34 +01:00
for input_value, output_value in tests:
payload = {"text": input_value}
msg = self.send_webhook_payload(
self.test_user,
self.url,
payload,
content_type="application/json",
)
webhooks: Rename assert_stream_message to assert_channel_message.
2024-05-04 22:09:56 +02:00
self.assert_channel_message(
slack_incoming: Fix formatting fixups with overlaps, or at start/end. The previous regular expression required a `[^\w]` at the start and end of the match. This had two unintended effects -- it meant that it could never match at the start or end of a string, and it meant that *adjacent* words required *two* non-word characters between them, as the pattern matches cannot overlap. Switch to allowing string start/end to anchor the matches, and make the trailing `[^\w]` be a zero-width look-ahead, to allow the patterns to overlap. Also remove the spurious `^` within the inner character classes, which prevented `*foo^bar*` from matching. Finally, add tests to cover the functionality, which was previously untested.
2022-11-29 22:10:34 +01:00
message=msg,
webhooks: Rename stream_name to channel_name arg.
2024-05-04 22:24:07 +02:00
channel_name=self.CHANNEL_NAME,
slack_incoming: Fix formatting fixups with overlaps, or at start/end. The previous regular expression required a `[^\w]` at the start and end of the match. This had two unintended effects -- it meant that it could never match at the start or end of a string, and it meant that *adjacent* words required *two* non-word characters between them, as the pattern matches cannot overlap. Switch to allowing string start/end to anchor the matches, and make the trailing `[^\w]` be a zero-width look-ahead, to allow the patterns to overlap. Also remove the spurious `^` within the inner character classes, which prevented `*foo^bar*` from matching. Finally, add tests to cover the functionality, which was previously untested.
2022-11-29 22:10:34 +01:00
topic_name="(no topic)",
content=output_value,
)
slack_incoming: Handle explicit None text payload in webhook.
2021-07-13 01:26:09 +02:00
def test_null_message(self) -> None:
self.check_webhook(
"null_text",
expect_noop=True,
)
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
def test_message_as_www_urlencoded(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "devops"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message = """
:zap: chris has started deploying project tag v0.0.2rc10 to staging
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
"urlencoded_text",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message,
python: Use trailing commas consistently. Automatically generated by the following script, based on the output of lint with flake8-comma: import re import sys last_filename = None last_row = None lines = [] for msg in sys.stdin: m = re.match( r"\x1b\[35mflake8 \|\x1b\[0m \x1b\[1;31m(.+):(\d+):(\d+): (\w+)", msg ) if m: filename, row_str, col_str, err = m.groups() row, col = int(row_str), int(col_str) if filename == last_filename: assert last_row != row else: if last_filename is not None: with open(last_filename, "w") as f: f.writelines(lines) with open(filename) as f: lines = f.readlines() last_filename = filename last_row = row line = lines[row - 1] if err in ["C812", "C815"]: lines[row - 1] = line[: col - 1] + "," + line[col - 1 :] elif err in ["C819"]: assert line[col - 2] == "," lines[row - 1] = line[: col - 2] + line[col - 1 :].lstrip(" ") if last_filename is not None: with open(last_filename, "w") as f: f.writelines(lines) Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-04-10 05:23:40 +02:00
content_type="application/x-www-form-urlencoded",
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
)
slack_incoming: Process request payload directly in view.py. slack_incoming webhook previously used has_request_variables to extract payload from HttpRequest object first, before trying to access HttpRequest.body again in view.py. This caused an error when one sends a request without payload - it is forbidden to read from request data stream twice. Instead of relying on has_request_variables, this PR extracts payload depending on content type in view.py directly to avoid reading request data stream twice. Fixes #19056.
2022-04-24 09:32:05 +02:00
def test_message_without_payload(self) -> None:
self.url = self.build_webhook_url()
slack_incoming: Simplify empty POST test. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-07-05 21:28:29 +02:00
result = self.client_post(self.url)
slack_incoming: Process request payload directly in view.py. slack_incoming webhook previously used has_request_variables to extract payload from HttpRequest object first, before trying to access HttpRequest.body again in view.py. This caused an error when one sends a request without payload - it is forbidden to read from request data stream twice. Instead of relying on has_request_variables, this PR extracts payload depending on content type in view.py directly to avoid reading request data stream twice. Fixes #19056.
2022-04-24 09:32:05 +02:00
self.assert_json_error(result, "Missing 'payload' argument")
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
def test_message_with_actions(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "C1H9RESGL"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message = """
webhooks/slack_incoming: Update regex to correctly convert emphasis. This was a bug where we were converting _text_ to **text**. For emphasis we use the *text* format.
2021-06-24 16:44:49 +02:00
Danny Torrence left the following *review* for your property:
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
[Overlook Hotel](https://google.com) \n :star: \n Doors had too many axe holes, guest in room 237 was far too rowdy, whole place felt stuck in the 1920s.
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
[Haunted hotel image](https://is5-ssl.mzstatic.com/image/thumb/Purple3/v4/d3/72/5c/d3725c8f-c642-5d69-1904-aa36e4297885/source/256x256bb.jpg)
slack_incoming: Support "fields" in "section"s. This is a best-effort rendering of the "fields" of Slack incoming hooks, which Slack renders in two columns. We approximate them in a Markdown table, with some minor in-place replacements. Fixes #22228.
2023-01-04 21:08:26 +01:00
**Average Rating**
1.0
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
"actions",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
expected_message,
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
)
def test_message_with_blocks(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message = """
Danny Torrence left the following review for your property:
[Overlook Hotel](https://example.com) \n :star: \n Doors had too many axe holes, guest in room 237 was far too rowdy, whole place felt stuck in the 1920s.
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
[Haunted hotel image](https://is5-ssl.mzstatic.com/image/thumb/Purple3/v4/d3/72/5c/d3725c8f-c642-5d69-1904-aa36e4297885/source/256x256bb.jpg)
slack_incoming: Support "fields" in "section"s. This is a best-effort rendering of the "fields" of Slack incoming hooks, which Slack renders in two columns. We approximate them in a Markdown table, with some minor in-place replacements. Fixes #22228.
2023-01-04 21:08:26 +01:00
**Average Rating**
1.0
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
"blocks",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
expected_message,
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
)
def test_message_with_attachment(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "prometheus-alerts"
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
expected_message = """
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
## [[FIRING:2] InstanceDown for api-server (env="prod", severity="critical")](https://alertmanager.local//#/alerts?receiver=default)
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
:chart_with_upwards_trend: **[Graph](http://generator.local/1)** :notebook: **[Runbook](https://runbook.local/1)**
**Alert details**:
**Alert:** api-server down - `critical`
**Description:** api-server at 1.2.3.4:8080 couldn't be scraped **Details:**
• **alertname:** `InstanceDown`
• **env:** `prod`
• **instance:** `1.2.3.4:8080`
• **job:** `api-server`
• **severity:** `critical`
**Alert:** api-server down - `critical`
**Description:** api-server at 1.2.3.4:8081 couldn't be scraped **Details:**
• **alertname:** `InstanceDown`
• **env:** `prod`
• **instance:** `1.2.3.4:8081`
• **job:** `api-server`
• **severity:** `critical`
""".strip()
webhook tests: Rename main helper to check_webhook. Almost all webhook tests use this helper, except a few webhooks that write to private streams. Being concise is important here, and the name `self.send_and_test_stream_message` always confused me, since it sounds you're sending a stream message, and it leaves out the webhook piece. We should consider renaming `send_and_test_private_message` to something like `check_webhook_private`, but I couldn't decide on a great name, and it's very rarely used. So for now I just made sure the docstrings of the two sibling functions reference each other.
2020-08-23 15:49:24 +02:00
self.check_webhook(
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
"attachment",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
python: Reformat with Black, except quotes. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-12 08:19:30 +01:00
expected_message,
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
)
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
def test_complicated(self) -> None:
# Paste the JSON into
# https://api.slack.com/tools/block-kit-builder to see how it
# is rendered in Slack
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message = """
## Hello from TaskBot
Hey there 👋 I'm TaskBot. I'm here to help you create and manage tasks in Slack.
There are two ways to quickly create tasks:
**1️⃣ Use the `/task` command**. Type `/task` followed by a short description of your tasks and I'll ask for a due date (if applicable). Try it out by using the `/task` command in this channel.
**2️⃣ Use the *Create a Task* action.** If you want to create a task from a message, select `Create a Task` in a message's context menu. Try it out by selecting the *Create a Task* action for this message (shown below).
[image1](https://api.slack.com/img/blocks/bkb_template_images/onboardingComplex.jpg)
➕ To start tracking your team's tasks, **add me to a channel** and I'll introduce myself. I'm usually added to a team or project channel. Type `/invite @TaskBot` from the channel or pick a channel on the right.
----
[cute cat](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
👀 View all tasks with `/task list`
❓Get help at any time with:
- `/task help`, or
- type **help** in a DM with me
""".strip()
self.check_webhook(
"complicated",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message,
)
def test_attachment_blocks(self) -> None:
# On https://api.slack.com/tools/block-kit-builder choose
# "Attachment preview" and paste the JSON in.
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message = """
This is a section block with an accessory image.
[cute cat](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
This is a section block with a button.
slack_incoming: Support "fields" in "section"s. This is a best-effort rendering of the "fields" of Slack incoming hooks, which Slack renders in two columns. We approximate them in a Markdown table, with some minor in-place replacements. Fixes #22228.
2023-01-04 21:08:26 +01:00
| | |
|-|-|
| one | two |
| three | four |
| five | |
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
""".strip()
self.check_webhook(
"attachment_blocks",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message,
)
def test_attachment_fields(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message = """
Build bla bla succeeded
**Requested by**: Some user
**Duration**: 00:02:03
**Build pipeline**: ConsumerAddressModule
slack_incoming: Verify that keys exist before checking their value.
2022-11-29 22:11:07 +01:00
**Title with null value**
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
**Title without value**
slack_incoming: Verify that keys exist before checking their value.
2022-11-29 22:11:07 +01:00
Value with null title
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
Value without title
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
""".strip()
self.check_webhook(
"attachment_fields",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message,
)
def test_attachment_pieces(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message = """
## Test
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Support more syntax. This significantly extends the accepted support for Slack "blocks"[1], as well as their legacy "attachments"[2] syntax. Fixes: #21944. See also #22228, which this does not solve, but assuming we can decide which compromises to make, becomes a reasonably uncomplicated follow-up. [1]: https://api.slack.com/reference/block-kit/blocks [2]: https://api.slack.com/reference/messaging/attachments
2022-06-17 01:11:12 +02:00
expected_message,
)
mypy: Enable new error explicit-override. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-10-12 19:43:45 +02:00
@override
webhooks: Add a webhook capable of parsing Slack payloads. This adds a webhook that can be used to interpret standard Slack payloads. Since there are a ton of existing Slack integrations out there, having a webhook which can accept standard Slack payloads can significantly ease transition pains. Obviously this can't do everything that Slack payloads can (particularly WRT their widgets/interactions), but we can ingest text and parse out multi-block payloads into a message relatively reasonably.
2020-02-12 23:48:55 +01:00
def get_body(self, fixture_name: str) -> str:
if "urlencoded" in fixture_name:
file_type = "txt"
else:
file_type = "json"
return self.webhook_fixture_data("slack_incoming", fixture_name, file_type=file_type)
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
def test_attachment_pieces_title_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
Sample pretext.
Sample text.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
Sample footer.
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_title_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_image_url_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## [Sample title.](https://www.google.com)
Sample pretext.
Sample text.
Sample footer.
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_image_url_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_ts_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## [Sample title.](https://www.google.com)
Sample pretext.
Sample text.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
Sample footer.
""".strip()
self.check_webhook(
"attachment_pieces_ts_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_text_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## [Sample title.](https://www.google.com)
Sample pretext.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
Sample footer.
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_text_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_pretext_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## [Sample title.](https://www.google.com)
Sample text.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
Sample footer.
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_pretext_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_footer_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## [Sample title.](https://www.google.com)
Sample pretext.
Sample text.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_footer_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_title_link_null(self) -> None:
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name = "(no topic)"
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message = """
## Sample title.
Sample pretext.
Sample text.
[](https://pbs.twimg.com/profile_images/625633822235693056/lNGUneLX_400x400.jpg)
Sample footer.
<time:1655945306>
""".strip()
self.check_webhook(
"attachment_pieces_title_link_null",
webhooks: Rename *topic local variables to *topic_name. This is preparatory work towards adding a Topic model. We plan to use the local variable name as 'topic' for the Topic model objects. Currently, we use *topic as the local variable name for topic names. We rename local variables of the form *topic to *topic_name so that we don't need to think about type collisions in individual code paths where we might want to talk about both Topic objects and strings for the topic name.
2024-01-17 15:53:30 +01:00
expected_topic_name,
slack_incoming: Handle optional attachment fields aptly. This commit checks for null values for keys within "attachment" in the Slack integration's incoming payloads. These keys were expected to exist optionally previously, and the existence of null values for these wasn't anticipated. Due to an issue report for such null values in the payload, their handling is updated appropriately. The checks for these values are truthiness checks since the strategy for these values being null or falsy ("", 0) is the same; we don't process that key-value pair. This is consistent with how Slack handles this scenario. For the case where all the attachment fields have null values, Slack displays this as an empty block with no content, and therefore our strategy for this is a no-op. Tests updated.
2022-08-16 21:53:31 +02:00
expected_message,
)
def test_attachment_pieces_all_null(self) -> None:
self.check_webhook("attachment_pieces_all_null", expect_noop=True)