Previously, the integration's name was directly being used.
Due to this, the GitHub Sponsors integration which is in the same module
as the GitHub integration could not be used with the
`generate-integration-docs-screenshot` script, as it would be unable to
locate the fixtures.
Add a `fixtureless_group` of arguments to allow passing in the message,
topic and channel via the commandline.
By default, the script uses the screenshot config from
`integrations.py`.
Example screenshots can now be generated for fixtureless integrations,
by sending mock messages using the topic and message text included in
the screenshot config added in the previous commit.
This is in preparation of adding support for generating screenshots of
fixtureless integrations, which would need to get image_path, without
involving fixture_path.
This is in preparation to differentiate the current config dataclass
(used for webhooks) from the FixturelessScreenshotConfig that will be
added for non-webhook integrations in the following commits.
- Removed the BaseScreenshotConfig dataclass, and merge it with
ScreenshotConfig dataclass.
- Simplified get_fixture_and_image_paths.
- Simplified generate_screenshot_from_config in the screenshot script.
- Deleted send_bot_mock_message.
- Simplified the loading of commandline options into the config dict.
- Split the logic into two new functions. This is in preparation to
later commits that will parse commandline options for non-webhook
integrations by re-using the created functions.
Group argparse arguments into common and webhook-specific options.
The common group contains arguments that apply to both webhook and
non-webhook integrations. It is not assigned a description.
A fixtureless, non-webhook group will be added later, when its arguments
are created.
to `fixture-name` to match the name of the corresponding field in the
ScreenshotConfig dataclass.
This is in preparation to loading all the options into a config dict
in a single step in a later commit.
Rename `group` to `batch_group`.
It's a mutually exclusive group that lets the user decide whether to
generate screenshots one at a time or in a batch.
Fixes#31248.
For cases with zero tabs in our current help center, we were using the
tab syntax just to put a border around the instructions without any tab
label. We do not want that border anymore since Tabs also don't have any
borders. So, we just remove the old tab syntax in that case during our
conversion.
We also move the admonition to asides conversion before the tabs syntax
conversion since the tabs conversion happening first was messing with
the asides conversion and was resulting into some missing closing tags.
We can modify things to work regardless of order, but doesn't seem worth
digging into for a conversion script.
The fill color is ignored when we generate webfonts in our main app.
For our help center beta project using Astro, we would have needed to
come up with a way to change fill colors for all the icons. Since, there
was no reason for us to keep the fill colors in the SVGs, we decided to
remove it instead and add a lint rule to keep that in check.
See
https://chat.zulip.org/#narrow/channel/6-frontend/topic/fill.20in.20our.20current.20svg.20icons
for more details.
Using postfix to handle the incoming email gateway complicates things
a great deal:
- It cannot verify that incoming email addresses exist in Zulip before
accepting them; it thus accepts mail at the `RCPT TO` stage which it
cannot handle, and thus must reject after the `DATA`.
- It is built to handle both incoming and outgoing email, which
results in subtle errors (1c17583ad5, 79931051bd, a53092687e,
#18600).
- Rate-limiting happens much too late to avoid denial of
service (#12501).
- Mis-configurations of the HTTP endpoint can break incoming
mail (#18105).
Provide a replacement SMTP server which accepts incoming email on port
25, verifies that Zulip can accept the address, and that no
rate-limits are being broken, and then adds it directly to the
relevant queue.
Removes an incorrect comment which implied that missed-message
addresses were only usable once. We leave rate-limiting to only
channel email addresses, since missed-message addresses are unlikely
to be placed into automated systems, as channel email addresses are.
Also simplifies #7814 somewhat.
Fixes#31249.
We have converted `warn` to `note` since that was the translation that
remains most faithful to how we display `warn` admonitions in our
current help center implementation. See
https://chat.zulip.org/#narrow/channel/19-documentation/topic/Stage.202.3A.20New.20syntax.20for.20!!!tip.20in.20help-beta/near/2174415
for more details.
We've also duplicated code from Python-Markdown to represent how
admonitions worked there more accurately. Duplication should be fine
since this is a one-off script and Python-Markdown is not a project
that's gonna change drastically in the future.
Earlier, we were just renaming the files in help/include and copying
them over. Which meant that none of the mdx features or any of the
components we add could be used there. We could also not support nested
imports which are a part of the help/include files.
We also set an explcit height and width of 1em for icons, since some odd
behaviour for icon height and width was noticed when writing this
commit. unplugin-icons sets height and width by itself. It was setting
the height to 1024 and 960 for some icons. It is better to set the
height explicitly.
The previous logic could not handle adding the given string at the 1st
line. We also rename the function to accurately represent what it does,
insert_string_at_line.
In future, we intend to add a function that will read the include files
and do a conversion to mdx. That conversion will be different from the
conversion that we are doing right now for the main help files. That is
why we have extracted the markdown file reading logic to the
`get_markdown_string_from_file` and renamed `convert_string_to_mdx` to
`convert_help_center_file_to_mdx` to be more specific for help center
files.
In `replace_icons`, when replacing zulip icons, the original
`markdown_string` was being passed instead of the result from the
previous font-awesome icon replacement.
In our app, we use the font-awesome stylesheet, add it to our webpack
bundle and use the appropriate class with the <i> tag.
Here. although for font-awesome, we can use the stylesheet to do the
same, we would need to use `webfonts-loader` for our custom icons.
In this astro project, we want to follow the Astro way, and
unplugin-icons fits better with the Astro way of doing things.
See this topic on the discussion on how we chose unplugin-icons:
https://chat.zulip.org/#narrow/channel/19-documentation/topic/Stage.202.3A.20Icons/near/2168842
Before this, every function itself was responsible for adding it's own
imports. That is extra string manipulation which we had to think about
everytime we were adding new conversion function.
Now, we have an import statement set that the functions can modify, and
we have a function responsible for adding those imports. This makes it
easier in the future to add more conversion functions which might be
introducing imports.
Vite introduced allowedHosts config at
https://vite.dev/config/server-options#server-allowedhosts. This caused
our help beta dev server to break in case of dev droplets since it's
hostname is not specified in the allowed lists. Since we have a way to
know our hostname, we do not pass a blanket true for all hostnames in
this case.
This commit
- Replace the blank option with an italicized option that's the current
default language, if there is one selected with "default" label.
- Make the "text" option more informative by adding (no highlighting)
to the label.
- Remove the hint for "text".
- Prioritize as left to right, before start typing:
blank/default language, text, quote, spoiler, math, everything else...
fixes: #33682
Fixes#31252.
One of our major use cases for file imports is to have bullet points as
partials to import at different places in the project. But when
importing the file with Astro, it creates its own lists. So we merge
lists together if they have nothing but whitespace between them.
There were some talks to use a component called FlattenList that would
flatten the list inside it, but that would also flatten lists that were
nested on purpose. This approach while feeling a bit hacky would not
flatten nested lists.
We use all these markdown files in `include` only to import them into
our main help markdown files. Most of these files are bulleted lists of
text. When importing these files, they might appear as an indented
sublist of an existing list. We plan to introduce mechanism to flatten
it in further commits.
