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.
Fixes CI - it was failing due to the API test for organization exports,
which was returning an error due to there being no Organization Owners
with consent to private data export.
To zulip/python-zulip-api, to keep them closer to their source code.
- Renamed the generate_zulip_bots_static_files to
generate_bots_integrations_static_files to accomodate the new function.
- Added a new function to
tools/setup/generate_bots_integrations_static_files to copy the
integration docs into static/generated/integrations.
- Updated integrations.py and computed_settings.py to use the new doc
paths.
- Deleted the affected integration docs.
- Updated the dependency URL.
Build warnings are unfortunately very common in third-party packages.
They’re difficult to reliably detect since packages don’t always build
from source, and they can’t be whitelisted on a per-package basis
since they’re all attributed to setuptools or an anonymous code
string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit serves as the base commit for redesigning the alert banners
by migrating them to use the new banner component. We use a new name
to refer to these banners — "Popup banners", which is more descriptive
about their behavior.
The Popup banners are appended to the container in a stacking order,
i.e., the most recent popup banner appears on the top and the oldest one
is sent to the bottom of the stack. These banners also inherit the
animations from the alert banners for visual appeal.
This commit also fixes the bug where clicking on the "Try now" button
in the popup banner resulting from an error in the `/json/messages`
endpoint resulted in call to restart_get_events in server_events.js
instead of load_messages in message_fetch.ts.
Fixes#31282.
`deliver_scheduled_emails` tries to deliver the email synchronously,
and if it fails, it retries after 10 seconds. Since it does not track
retries, and always tries the earliest-scheduled-but-due message
first, the worker will not make forward progress if there is a
persistent failure with that message, and will retry indefinitely.
This can result in excessive network or email delivery charges from
the remote SMTP server.
Switch to delivering emails via a new queue worker. The
`deliver_scheduled_emails` job now serves only to pull deferred jobs
out of the table once they are due, insert them into RabbitMQ, and
then delete them. This limits the potential for head-of-queue
failures to failures inserting into RabbitMQ, which is more reasonable
than failures speaking to a complex external system we do not control.
Retries and any connections to the SMTP server are left to the
RabbitMQ consumer.
We build a new RabbitMQ queue, rather than use the existing
`email_senders` queue, because that queue is expected to be reasonably
low-latency, for things like missed message notifications. The
`send_future_email` codepath which inserts into ScheduledEmails is
also (ab)used to digest emails, which are extremely bursty in their
frequency -- and a large burst could significantly delay emails behind
it in the queue.
The new queue is explicitly only for messages which were not initiated
by user actions (e.g., invitation reminders, digests, new account
follow-ups) which are thus not latency-sensitive.
Fixes: #32463.
This is valuable so that one is forced to explicitly make a decision
on what is correct when adding new callers. Past experience tells us that
not having to explicitly show the decision leads to people introducing
security bugs in PRs that the maintainer has to catch in review, and our
goal for access control code should be that security bugs are hard to write.
Fixes#33688.
