This commit fixes a flake in `do_delete_messages`, because of
which `test_do_delete_messages_grouping_logic` test occasionally
failed due to nondeterministic ordering of "delete_message" events.
The root cause was that the dictionaries used to group private
and stream messages for deletion (`private_messages_by_recipient`
and `stream_messages_by_topic`) were not sorted before generating
the events. While the `message_ids` within each event were already
sorted, the order of the events themselves could vary based on
the insertion order of the dictionaries, especially when running
tests in different sequences.
We now sort both `private_messages_by_recipient` and
`stream_messages_by_topic` before emitting events, ensuring
consistent ordering.
The call from the inbox code was asking the wrong question -- it wants
to know if we've fetched full topic data to know whether to ask for
it. The new name for the function moved in
7d55ad3c13 helped reveal it.
There also was a mention in a comment that was half-baked; wrote the
comment properly.
Updates the "Mention a user or group" article to have a tip that
links to the section on how message notifications work for mentions
when editing a message's content.
Showing these realms in the drop down list of realms is not helpful
for developers, so we filter them out of the list. Realms that are
deactivated without a redirect are still listed.
Sending messages to a deactivated stream is not allowed with
the exception of notices sent in "channel events" topic.
Earlier, notice sent to a deactivated stream when it is
deactivated was working correctly but it was resulting in
an error in the following cases:
* Renaming stream
* Changing stream description
* Changing message retention period
* Changing posting permission
* Changing access permission
This commit makes sure to send notice successfully in those cases.
Earlier, when number of topics displayed in the topic list
widget was at max `topic_list_data.max_topics` and
first_message_id of stream >= first_cached_message_id.
There was a possibility of a few topics missing for messages
which were sent when the user wasn't subscribed.
We were neither displaying 'show more topics', nor fetching it
from server to update the list asyncronously.
This commit fixes that bug to display 'show all topics' in that
case and also initiates an API call in parallel to fetch all topics
for that stream and update the topic list asyncronously if topics
were actually missing.
Fixes#28949.
A prep commit to move `is_complete_for_stream_id` and
`all_topics_in_cache` from `stream_topic_history` to `topic_list`
as it is specifically used while building topic list widget.
As it makes more sense to use `is_complete_for_stream_id` instead of
`all_topics_in_cache` directly, we reorganize to put it inside
`is_complete_for_stream_id`.
We rename `is_complete_for_stream_id` to
`is_full_topic_history_available` for clarity.
It'll also help to avoid tackling circular import issue
while resolving #28949.
No functional change in this commit.
Earlier, we were using `all_messages_data.first()` for the oldest
message ID we have in cache, which is incorrect.
`all_messages_data.first_including_muted()` returns the oldest ID.
This commit fixes the bug.
Previously, if `get_server_history()` was called while a request
for the stream was already pending, the provided `on_success`
callback was ignored.
This commit fixes that by queuing all `on_success` callbacks per
stream_id when a request is already in flight. Once the request
completes, all queued callbacks are executed.
This commit updates code to use "\x07" as value for
"subject" field of Message objects for DMs and group
DMs, so that we have a unique value for DMs and group
DMs which cannot be used for channel messages.
This helps in avoiding having an empty string value as
topic for DMs, which is also used for "general chat"
channel messages, as large number of DMs in the realm
resulted in PostgreSQL query planner thinking that there
are too many "general chat" messages and thus generated
bad query plans for operations like fetching
"general chat" messages in a stream or moving messages
to and from "general chat" topic.
This change as done for ArchivedMessage and
ScheduledMessage objects as well.
Note that the clients still get "subject" value as
an empty string "".
This commit also adds tests for checking that "\x07"
cannot be used as topic for channel messages.
Fixes#34360.
Slackbot should be correctly marked as a bot rather than a regular user
- otherwise, it confusingly appears on the Users list and in the realm
creation from Slack import flow, in the dropdown for choosing the
organization owner account.
Closes#34649
When selecting the realm owner is not needed in the realm creation from
Slack flow, we don't set need_select_realm_owner value on the
preregistration_realm object. Thus, this codepath cannot expect to
always find the key - and instead should use .get(), defaulting to False.
When a realm is a placeholder realm due, i.e., the realm redirects
to another URL due to previously changing the realm's subdomain,
we only show the redirect information.
There is a copy link that for the redirect URL that can be pasted
into the search bar to get to the support view for the actual
realm.
For confirmation objects that do not show realm details, but have
a realm object, format the header information to match what we do
show in the realm details page and show the realm's subdomain.
Creating a demo organization will not require the user to
set either an email or password, so explicitly set the
password field to not be required for that case.
Updates the form submitted in the dev environment to create
a new demo organization to not send a password value.
This prevents the case when we have text like `[abcd](url)`
in the compose box and the "url" part is selected, and we paste
a link copied from message actions popover.
Though the frontend module generated correct urls for
empty topics, it would sometime generate incorrect
link text in the fallback md link syntax. (eg, if
empty string was provided as the topic name).
This commit fixes that.
