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, '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.
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.
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
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`.
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.
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.
We currently always show fa-ban icon and "Disable" text for
"Disabled" or "None selected" option in dropdown-list widget.
This commit adds code to provide an option for not showing the
fa-ban icon and having the option text be something other than
"Disable". This will be used in channel folder dropdown widget
where we want to have "None" text in the option without icon.
Fixes
https://chat.zulip.org/#narrow/channel/9-issues/topic/Starred.20messages.20view.20performance/near/2184251.
Anchor for starred messages was `first_unread` and the query to find
first_unread in a user's starred messages can turn out to be expensive.
This commit ensures that we default to newest instead since first_unread
is not of important for the starred messages view.
By excluding starred messages from using `first_unread`, it will default
to newest based on the logic in message_view.ts.
This commit adds an option to change the notification settings
of a channel from default to custom in the Notifications menu
of Personal settings.
Fixes#19849.
This commit adds a variable `push_notifications_disabled` to the
checkboxes used in the notifications table in Settings > Notifications.
The variable is used to control the mobile push notifications
disabled tooltip.
We shouldn't show duplicate suggestions in the typeahead, but
duplicate pills were still possible by typing a term twice in
the search bar and pressing enter after each one, and this
commit prevents that from putting duplicate pills in the search
bar.
Previously, typing "channels: public" would show "Channels public"
in the typeahead, which was especially confusing because we'd show
"All public channels" until the term was completely typed out.
Calling settings_data.user_can_access_all_other_users on every call to
this function could be expensive when using this function in loops
over every user in the organization.
After the previous commit, those calls are still somewhat expensive
for guest users.
This fixes an important issue where this function being called in a
loop can consume as much as 1ms per iteration for users who are in a
lot of groups.
Earlier, we were appending view all subscribers link using
JQuery.append, which leaves open the possibility for the component to
be appended multiple times if the function calling it gets called
multiple times.
It is better to have the link div in right_sidebar.hbs
and then insert the html when required.
Searching e.g. "NASA" would put "nasa" in the search bar if you
selected "search for NASA" in the typeahead. This probably looks
weird to users, so let's not lowercase search operands.
This commit laying the groundwork for dynamic re-rendering of
drafts.
Previously, the draft list was rendered once with the overlay,
and re-rendering wasn't needed. However, to support features like
"undo," we now need to re-render the draft list dynamically.
Earlier, keyboard shortcuts were not supported for non-latin
keyboard layouts.
This commit adds support for it.
Keyboard can be:
* configured to type latin text, with the QWERTY, AZERTY, etc layout.
* configured to type non-latin text.
For non-latin users, if a shortcut requires a key and it is not
present on the keyboard, they press the same physical key that a
QWERTY user would press.
Pressing QWERTY equivalent key is not a Zulip specific requirement,
non-latin users have confirmed in CZO that they use the same behaviour
on other applications.
Algorithm:
We need to determine the key combination pressed in a consistent way,
irrespective of the keyboard layout.
For keyboard layouts (e.g. QWERTY) where `event.key` results in
printable ASCII characters or named key attribute values like "Tab",
"Enter", etc., we use `event.key` directly to determine the key
combination.
For layouts where the character defined for a hotkey can't be typed
directly (e.g. 'a' in Cyrillic), users press the same physical key
combination that a QWERTY user would use (e.g. 'ф' on Cyrillic maps
to 'a' on QWERTY). In such cases, we derive the key combination
(QWERTY equivalent) using `event.code` and the `CODE_TO_QWERTY_CHAR`
map.
Here `event` is "keydown" event.
Once, the key combination is determined the action to perform is
executed.
Fixes: #19605.
Earlier, with Caps Lock enabled, pressing letters like 'a', 'i', etc
resulted in the keyboard shortcuts for 'Shift+A', 'Shift+I', etc
getting executed. Ideally, they should work only when 'Shift + Key'
is pressed.
We used to check capitalized letters, which can result either due
to `key` pressed with Caps Lock enabled or `Shift + key` pressed.
This commit fixes the bug by using the event modifiers states to
construct a fully descriptive string like 'Cmd+Ctrl+Alt+Shift+A',
and then look up that string in a single mapping for further execution.
We treat a-z letters case-insensitively. We distinguish between
'a' and 'A' as 'A' vs 'Shift+A'.
This descriptive string approach also resolves a bug where
`Ctrl + Meta + C/K/S/.` was working. We define the valid hotkey as
`Meta + C/K/S/.` for macOS and `Ctrl + C/K/S/.` for others.
This commit removes the deprecated `keypress` event.
Now, we use the `keydown` event to handle all the cases.
Earlier, we used `keypress` because it allowed us to distinguish
between lowercase and uppercase characters using `event.which`.
For example:
* For 'r':
* keypress.which = 114
* keydown.which = 82
* For 'R':
* keypress.which = 82
* keydown.which = 82
As shown, `keydown.which` cannot distinguish between 'r' and 'R',
which is why `keypress` was helpful.
Now, modern browsers support `event.key` on `keydown`, which directly
gives 'r' or 'R' as needed. This makes `keypress` unnecessary, and
we can safely rely on `keydown` with `event.key` to get the exact
character.
An earlier commit in this PR #34570, in which we replaced
the `event.which` with `event.key` plays a major role as a prep
commit to help removing `keypress` event in this commit.
Earlier, 'H' and 'N' were being tested as unmapped keys and the test
was falsely passing because these keys are handled by `process_keydown`
but the test was processing it with `process_keypress`.
This commit removes those keys from the test.
We already test them with keydown in other tests.
