When offline, has_found_newest never ends up being true, and we'd end
up falling through to an interleaved banner. We rewrite this logic
with an explicit idea of whether we're online, and the following fixes:
- Never display the interleaved view confirmation banner in a
conversation view.
- Avoid displaying that banner inaccurately when the actual problem
is that we're offline.
- If we're offline, always call do_mark_unread with a list of IDs,
such that if its helpers supported local echo (they don't), we
will locally echo to the extent possible.
Note that following this change, being offline results in "mark
unread" being a noop until you're online again. Better than a weird
banner.
See https://chat.zulip.org/#narrow/channel/9-issues/topic/mark.20unread.20strange.20when.20disconnected/near/2201703 for more context.
This commit adds code to use
`web_left_sidebar_unreads_count_summary` from personal
settings in web app.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
Fixes part of #28759.
Earlier, when we had unread banner in message list and user marks
all messages as read for topic, unread banner would persist even
though we had no unread messages in current message list.
This commit hides unread banner when there are no unreads just like
we show banner when unread messages appear in message list.
Fixes:zulip#33866.
Earlier, 'all_topics_in_cache' used to return `false`
in the case where we were unsure if some topics were
present even before the user subscribed to the channel
and hence missing in the cache.
Returning `false` led to visible 'show all topics',
even if all the topics were already displayed. This was
helpful if the API call to fetch channel history failed,
as users had the option to make another request.
That resulted in a bug where "show all topics" was flashing
in channels with less number of topics. We used to display
"show all topics" initially and then hide it after the API
call confirmed that there were no new topics to display.
To fix this bug, we return `true`. So, the "show all topics"
is not displayed beforehand. We let the API call fetch the history
and rebuild the topic list based on the updated data.
Instead of show then hide. We now prefer, show if needed.
To fix the issue of API call failure and users having no option
to see all topics, we did prep work in the last commit
to add retry mechanism to the concerned API call.
Earlier, in `get_server_history` the API call to fetch stream-topic
history didn't have a retry logic.
This commit adds a retry mechanism.
If the request to fetch stream topic history fails, we now retry
the request up to a fixed number of times before giving up.
This improves UX in case of temporary network issues.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
Previously, when sending messages to resolved topics, the warning
suggesting to resolve that topic used wrong check to verify if the
user is allowed to resolve the topic. This commit fixes that.
Some browsers trigger a 'keydown' event with `key === undefined`
on selecting autocomplete suggestion. These are not real keypresses
and can be safely ignored.
See: https://issues.chromium.org/issues/41425904
Earlier, not handling it was resulting in error later in the codepath.
We make the text "minutes" agree with the number
in the input field.
In the future, we could make the units configurable
as in the invitation modal.
Fixes#34692.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Previously, the placeholder in the "Rename topic" input
overlapped with the text when renaming the "general chat"
topic. Also, the placeholder was not updated to "general chat"
when the input was empty and lost focus. This commit fixes the bug.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
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`.
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.
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 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.
