Update to maintain consistency with the value of the context property
used in the other docs.
We avoid using the context property for these instances because we
always want them to show "your-org.zulipchat.com" irrespective of the
domain the docs are hosted in. Hence, the manual replacements.
The subdomain and host parts are already used within zulip_url, api_url,
this commit adds them as context properties themselves, so that they
can be used in email addresses and URLs without the URI scheme,
increasing uniformity.
The new context properties `display_host` and `display_subdomain` are
usable in the Help, API docs and Policies.
Occurrences of `*.zulipchat.com` have been updated to use them.
Since non message views list channel topic list can have a defined
filter, we cannot assume that having `narrow_state.filter` set
implies `message_list.current` is defined.
It was not a good idea to have the hotkey
fallthrough the `case` for user not being in message list.
We merge both the cases and also remove `M` from
`message_view_only_keys`.
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.
