Displays "Several people are typing..." when more than 3 users
are typing to avoid typing notifications in streams being too noisy.
A side effect is it shows the same message in pms too.
Muted users are stored in a map with key as user ID and
the value as the timestamp of muting.
Names can be easily fetched from existing functions
in `people.js` and hence not stored.
Within 9c9d74fd6d, page_params.is_realm_admin was incorrectly
stated while building popover which lead to admin actions not
being populated within popover.
This is so beacuse `is_realm_admin` is not a valid object
of page_params.
Rectified by renaming `is_realm_admin` to `is_admin`.
This is a prep commit for implementing mute users feature, which
renames this function to be more specific. This function cannot be
used as-is for user mutes, because for user-muted messages, we always
want to rerender the message list, irrespective of what
`excludes_muted_users` is.
In muting_ui.js, we also remove an unnecessary conditional that is
already handled by update_topic_muting_and_rerender itself.
Previously, the recent-topics view did not update when the webapp
received `muted_topics` events.
The final state was correct **only** on the client which was used to
mute/unmute the topic, because we update the UI even before sending
the request to the server to mute/unmute the topic.
This commit fixes that by rerendering the recent-topics table when the
client receives `muted_topics` events. While doing so can be
expensive, it is likely unavoidable, because we may want to even
remove the topic from the recent-topics table, and we don't know
exactly which topic was affected (we just get an updated list of all
muted topics from the event).
Even though rerendering is expensive, it should not affect the user
experience, because a rerender will be trriggered only in the clients
which did not do the (un)muting (and hence, the user was probably not
interacting with these clients when the event was received). The
`last_topic_update` variable makes sure that this is the case.
Previously, on clicking the "bell" icon from a recent
topics topic row, two click handlers were triggered-
1. The one for the bell in the recent-topics topic
row.
2. The one for the bell in the floating recipient bar.
This is intended to be triggered only when the user
clicks on the bell icon in the floating recipient
bar to mute a topic, but this was triggered on
clicking the recent-topics topic row bell too,
because it wasn't specific and we use the same
HTML class for both the bells.
Because both these click handlers were triggered,
the webapp sent back-to-back duplicate requests to
the server to mute the topic, which caused the sever
to throw "HTTP 400: Topic already muted" error.
This commit fixes this by making the recipient bar
click handler more specific, so that it is triggered
only when the recipient bar bell icon is clicked.
There is also the issue that the recipient bar bell
icon only allows a user to mute the topic, not unmute.
So, when someone mutes a topic, and then clicks on
the recipient bar bell icon, the webapp sends a
request to mute the topic again (not to unmute),
leading to the same error as above.
This commit does not fix that. See #15223.
Added a `include_current_item` parameter to dropdown_list_widget
which behaves as follows:
- Has a default value of `true`, which includes the current value
in the dropdown list items.
- If set to false, it excludes the current value from dropdown
list items.
This fixes a bug I introduced when merging
86eccfd20f, by not using the "new topic
button" trigger.
It would probably be wise to replace that "trigger" system with just
passing actual options, as it's pretty confusing.
This commit adds an option to create new topic in stream
popovers. Then adds a click listener on them which triggers
the compose start function with the stream specified.
Fixes#13480.
Fixes#2507.
We use GIPHY web SDK to create popover containing GIFs in a
grid format. Simply clicking on the GIFs will insert the GIF in the compose
box.
We add GIPHY logo to compose box action icons which opens the GIPHY
picker popover containing GIFs with "Powered by GIPHY"
attribution.
This change should make live-update code less brittle,
or at least less cumbersome.
Instead of having to re-compute calculated fields for
every change to a stream message, we now just compute
the fields right before we render stream settings UI.
This is mostly a pure code move.
In passing I remove an unneeded call to
update_calculated_fields in the dispatch code,
plus some tests that don't need them.
This maps pageup/pagedown/home/end to close compose when used in empty
compose box, matching the existing behavior for the Up/Down arrow keys.
Currently, these keys do nothing when used in an empty compose box.
Typically, a user intends to navigate when pressing these keys (and
with empty compose, they can't be expecting to navigate within the
compose box), so it makes sense to map them to navigate the message
feed just to save users from needing to hit `Esc` in these contexts.
Fixes#17917
The `copy_handler` function that this shortcut calls is not useful
unless the body of a Zulip message is selected, so we shouldn't try
running it in other situations.
This logic correctly prevents the hotkeys implemented below it from
being active when "Recent topics" is open. We expect to change some
parts of that soon (see #17685), but in any case, we should always
return false in the hotkey code when we don't process a key, so that
default browser behavior works.
This fixes browser shortcuts like Ctrl+C, Ctrl+V, etc. when recent
topics is loaded.
This bug was introduced in 1eafb1d8b3.
Thanks to ganpa3 for noticing this bug.
This sorts the members imported within each individual declaration; we
use import/order for sorting multiple declarations.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For filter values which don't exist or are invalid in some
way, we return false to show user that there are no messages
in the filter user is trying to render. Our previous behaviour
was to show all the messages and ignore the filter which
isn't good.
This reverts commit a00f5dd90e (#17801).
That commit introduced a regression in the portico pages as described
in commit 85b3157b47. Since that fix
introduced a regression of its own, we need to revert both commits for
now.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The start time of the last password change was the wrong time to use,
because we could start a password change, start another request,
finish the password change, and then observe that the other request
failed due to the password change.
We could use the end time, but a counter is more robust to
sub-millisecond race conditions.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commits adds on to 9884226f, which was added to
handle a rare race condition that occurs when the
session hash is not updated by the backend during the
password change process.
It handles a variant race situation where the request was initiated
before/during the password change event and completed after it was
completed. Hence, forcing the page to redirect to the login page.
This commit make compose_ui.autosize_textarea handle most of the autosize
logic of the textarea. It audits for any logic that is trying to do
autosize manually and replace it with compose_ui.autosize_textarea.
This allows to have better check for when the textarea is autosized.
Mainly done this so that we can have a check on #compose-textarea when
to autosize and when not to, thus helping to have all the logic in only
one function.
We now unconditionally enable backgroung events when 'hidden.bs.modal'
event is triggered on closing of modal. We do not need to handle them
separateley for closing modal by close_modal, data-dismiss or escape.
We handle this by single handler for modals in settings and subscription
overlay.
Fixes#16688.
This commit changes the code to not remove the modal element from DOM
after closing the modal for the deactivation stream modal and stream
privacy modal.
This is a prep commit for enabling background mouse events
unconditionally using 'hidden.bs.modal', because removing element
using '.remove' remove all events attached to it and this will also
remove the 'hidden.bs.modal' event which we do not want.
This remove behavior is inconsistent as we remove some of the modals
but do not remove some, so for now we are not removing the modal
after closing but it is anyway removed before opening a modal to handle
case of having two elements of same id and avoids any bugs.
This behavior of when to remove the element from DOM and when to not
remove needs to be discussed and may be modified in future.
We show a modal as a warning when unsubscribing a private stream
because it is a irreversible action and one cannot re-subscribe
tovit until added by other member of stream.
Fixes#9254.
This commit renames the class of both cancel button and the cross
icon to close-modal-btn.
This change is a prep commit for enabling background events on
'hidden.bs.modal' event. As we would enable background events in
furhter commit using the 'hidden.bs.modal' event, we would need to
remove the 'hide.bs.modal' event of deactivation_stream_modal which
removes the modal element from DOM.
When we remove this we would need a e.stopPropagation call to avoid
unexpected closing of subscription settings, which was not a problem
before as the element was removed from DOM before the actual closing
of modal.
So instead of adding a separate `e.stopPropagation' call, we can use
the same handler that is being used for stream privacy modal and this
is the reason the class name of cancel button of privacy modal is
being changed.
We do not remove the stream row instantly from the subscribed list in
subscription overlay when unsubscribing from public streams in most
of the cases but we do so when unsubscribing using hotkey.
This commit makes it consistent by not removing the stream row on
unsubscribing using hotkey.
We also not remove the 'active' class as streams settings is still
open in the right seciton and this behavior is also consistent with
the other ways of unsubscribing.
Note that this behavior is only for public streams, we remove the
stream row in case the stream is private, as user cannot
resubscribe himself and this behavior is consistent across all ways
of unsubscribing.
We now consistently set the PM counts for the right
sidebar toggle in unread_ui, similar to what we
do for the overall counts in the left sidebar toggle.
(Use a thin window to see the code in action.)
This breaks a dependency cycle.
In passing I improve the test coverage for the
actual job that pm_list still does (updating its
own total count in the "Private Messages" section).
Dinesh
Abhijeet Prasad Bodas
Anders Kaseorg
aryanshridhar
Tim Abbott
Signior-X
Aman Agrawal
Steve Howell
Ganesh Pawar
Mateusz Mandera
YashRE42
Riken Shah
sahil839
Sumanth V Rao