The presence of `len(messages)` outside the transaction caused the
full resultset to be fetched outside of the transaction. This should
ideally be inside the transaction, and also only need be the count.
However, also note that the process of counting matching rows, and
then executing a second query which embeds the same query, is
susceptible to phantom reads, where a query with the same conditions
returns different resultsets, under PostgreSQL's default transaction
isolation of "read committed." While this is possible to resolve by
pulling the returned IDs into a Python list, it would not address the
issue that concurrent updates which change the resultset would make
the overall algorithm still incorrect.
Add a comment clarifying the conditions under which the algorithm is
correct. A more correct algorithm would walk the UserMessage rows
which are unread and in the stream, but this requires a
whole-UserMessage index which would be quite large for such an
infrequent use case.
This makes no immediate reloads the default for runtornado, matching
the production configuration, and changes the development incantation
to be the one to specify the departure from the norm, with
--immediate-reloads.
LoggingCountStats with a daily duration and that are directly stored
on the RealmCount table (not via aggregation in process_count_stat),
can be in a state, after the hourly cron job to update analytics
counts, where the logged value will be live-updated later, because
the end time for the stat is still in the future.
As these logging counts are designed to be used on the self-hosted
installation for either debugging or rate limiting, sending these
partial/incomplete counts to the bouncer has low value.
These are fine instructions, but are specific to the server and
web app, while the surrounding section is otherwise valid for the
project as a whole. Mark them as such, and add a sibling item
for the Flutter app. (Consisting of good advice for becoming
familiar with really any software project, plus a link to the
app's README for specific setup instructions.)
Due to the channel_map_to_topics URL parameter in the Slack webhook,
it was not migrated to use the check_send_webhook_message.
By using check_send_webhook_message, any topic parameter in the
webhook URL will be prioritized over mapping Slack channels to
topics, e.g. when channel_map_to_topics is true. This is because
the default behaviour for incoming webhooks is to send a default
topic as a parameter to check_send_webhook_message in case there
is no topic specified in the URL.
In contrast, we can override the stream passed in the URL when
channel_map_to_topics is false by passing the Slack channel name
to check_send_webhook_message. The default behaviour for incoming
webhooks is to send a direct message if there is no specified
stream in the URL, so a default stream is not generally passed
to check_send_webhook_message.
Fixes#27601.
This change aids in differentiating between a normal user and a bot
account, furthur eliminating any confusion between them (a step forward,
considering how good LLM bots have become in impersonating a real user).
Fixes#25958.
Co-authored-by: 1010nishant <nishantjangid6377@gmail.com>
This commit adds a realm-level setting named
'zulip_update_announcements_stream' that configures the
stream to which zulip updates should be posted.
Fixes part of #28604.
It doesn't make sense for us to track a separate current filter when
it should just the be filter of current message list if there is one.
This will reduce possible confusion in the codebase where filter
returned by narrow_state is different from message_lists.current.
- Updates API docs that have numbered instructions to use the
`{start_tabs}` formatting we use in the help center.
- Cleans up formatting and revises documentation that shouldn't
be formatted as a numbered instructions block.
- Cross-links related articles.
Fixes#28876.
The `upload_objects_by_message_edit_row` map object was being exported
to handle the uploads during the editing of a message. To improve the
abstraction, we move the logic being used to access
`upload_objects_by_message_edit_row` and itself into `upload.js`.
Similarly, the `compose_upload_object` constant which was being exported
to handle the cancelling of compose uploads. This commit removes this
export and instead defines a new method `compose_upload_cancel` to
handle the same.
Every time a user edits a message, we call the `setup_upload` method
which creates a new Uppy instance and adds some event listeners to
enable the upload process. These event listeners were not being removed
during the cleanup process of message editing, which led to multiple
event listeners being attached to the edit message form. Due to this,
multiple duplicate files would get attached via these multiple event
listeners if a user opened the edit message form for the same message
multiple times.
This commit adds the `deactivate_upload` method to perform all the
necessary cleanups while closing the edit message form. Via this
method, we remove the event listeners attached and close the Uppy
instance which cancels all uploads, resets progress and removes all
files.
Alex Vandiver
Lauryn Menard
Anders Kaseorg
Greg Price
Bedo Khaled
afeefuddin
Sayam Samal
Sahil Batra
Prakhar Pratyush
Tim Abbott
Alya Abbott
Mateusz Mandera
Aman Agrawal
David Rosa
evykassirer