`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.
Note that the puppeteer tests only tested
copying whereas the node tests only tested
pasting, which is why the puppeteer tests
for pasting and node tests for copying are
absent after this split.
This commit adds two new tools to avoid API feature level rebases:
`create-api-changelog`: Generates an empty changelog file for temporarily
recording API changes.
`merge-api-changelogs`: Merges temporary changelog files and increments
the API feature level.
A button has been introduced to launch a modal
for creating todo-lists directly from the compose box.
The modal features a form that, upon submission,
generates a message using the `/todo` syntax and the data
inputted in the form. Subsequently, the content of the compose box
is set to this message, which the user can then send.
This modal closely parallels the UI for adding a poll; therefore,
the poll and todo code has been shifted to a newly created
file named `widget_modal.ts`, and `poll_modal.ts` is now deprecated.
Co-authored-by: Sujal Shah <sujalshah28092004@gmail.com>
Fixes#29779.
This commit adds typing indicators for message editing in stream
as well as in dm, if the send typing notification
for corresponding is enabled.
Based on earlier work in #28585.
Co-authored-by: Rohan Gudimetla <rohan.gudimetla07@gmail.com>
Fixes#25719.
As part of the banner redesign project, this commit applies the new
banner styles to the desktop notifications navbar banner.
This commit also acts as a base for the following banner redesign
commits by defining the `banners.ts` module, which now acts as the
centralized module to handle the banner rendering and sets up the
common event listeners.
Fixes#33156.
If the stream is set to on the private settings for privacy, we add a
parenthesis text `must be subscribed`.
We had to use JS to change the string since just having a conditional in
the handlebars template would not ensure that the parenthesis text
appears or disappears on changing the value.
This commit replaces the spectrum color picker used in the stream
popover and stream settings with a custom color picker popover, which
contains a grid of predefined color swatches and a custom color option.
The custom color option uses the HTML5 <input type="color"> which shows
the native browser color picker UI.
Fixes#14961.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to `GET /messages`
and `GET /messages/{message_id}` endpoints to decide whether the
topic names in the fetched messages can be empty strings.
If False, the topic names in the fetched message will have the
value of `realm_empty_topic_display_name` field in `POST /register`
response replacing "" for channel messages.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds a `empty_topic_name` client capability to allow client
to specify whether it supports empty string as a topic name.
Adds backward compatibility for:
- `subject` field in the `message` event type
Earlier, when a topic was deleted then UserTopic rows corresponding
to that topic were not deleted resulting in a bug where the topic
is listed in the '/#settings/topics' panel even after deletion.
This commit fixes the incorrect behavior to delete the concerned
UserTopic rows.
We need to take special care of the case when a topic is deleted
in private channel with protected history. We delete the UserTopic
records for exactly the users for whom after the topic deletion
action, they no longer have access to any messages in the topic.
This commit completely eliminates the home-grown
data_types.py system for checking types.
Now, in our unit tests and schema checkers, we use
pydantic types to check the shape of the event
objects that are either in our JSON fixtures or
that get captured by test_events.py.
The code in event_types.py was completely
code-generated from the legacy version of
event_schema.py, so there shouldn't be any
manual errors in how I ported the types over.
(The code generation was non-trivial, though,
as I had to account for changes from
snake_case to CamelCase and deal with some
other anomalies.)
When we move away from `data_types.py` in favor of using
`pydantic` to describe the shape of our event objects in
the events test (hopefully coming soon), then the code
I deleted here will no longer work.
The consequence of this change is that API docs may
diverge from the actual event types that we use, but
I believe there are better ways to manage this.
Also, the deleted code was particularly hard to debug
(and I say that as the original author). It probably
also causes friction for folks who want to update the
docs but who don't necessarily grok how the event tests
work under the legacy `data_types.py` regime.
Once we get pydantic types working, we can probably
just write a separate tool to validate against them
against the API docs using the `openapi-schema-pydantic`
package or something similar.
This commit conditionally adds the source command for
virtualenv in the user's bash profile only when the
system is virtualized.
Checking WSL_DISTRO_NAME in the env vars
is the cheapest option in case of checking
whether the system runs as WSL VM since
it is an in memory operation.
Hence it is checked for first in `is_wsl_instace`.
Fixes#15029.
Made the input field of the page consistent with
the other similar pages. Here are I have done the following things:
1. Changed text 'Enter your organization's Zulip URL:'->'Organization URL'.
2. Left aligned the label and button to make it consistent.
3. Moved 'Don't know your organization URL? Find your organization.' to be
just below the URL field.
4. Changed the placeholder 'your-organization-url' -> 'your-organization'
Fixes#32198
