Previously, when the guest role was selected in the Invite modal and
guests were restricted from viewing all other users, there was no
indication of how many users the invited guests would be able to see
once they joined.
This commit resolves that issue by adding a note in the Invite modal
that dynamically informs users of the number of visible users.
Fixes#31159.
Previously, these were only shown for Mac OS users and replaced
the "Home", "End", "PgUp" and "PgDn" shortcuts. But as this really
depends on the keyboard the user is using (there are Mac keyboards
with the above keys), we instead show both options in our web app
and help center documentation on keyboard shortcuts.
The tooltip for the "Scroll to bottom" button will now always show
"End" for all users. Previously, it showed a "Fn" key option for
Mac users.
Fixes#31815.
'realm_upload_quota_mib` is updated when `plan_type` changes.
Earlier, we were including 'upload_quota' to update
`realm_upload_quota_mib` in extra_data field of 'realm op: update'
event format when property='plan_type'.
This commit migrate those two parameters to `realm op: update_dict`
event format.
* None of the clients processes these fields, so no compatibility
code required.
* Renamed `upload_quota` to `upload_quota_mib` as it better aligns
with our goal to encode units in the client-facing API names.
Also, it helps to avoid extra code to update 'realm_upload_quota_mib`
in web client, web client simply aligns with
'realm["realm_" + key] = value'.
Earlier we use to restrict admins, moderators or members of a group to
manage that group if they were part of the realm wide
`can_manage_all_groups`. We will not do that anymore and even
non-members of a group regardless of role can manage a group if they are
part of `can_manage_all_groups`.
See
https://chat.zulip.org/#narrow/stream/101-design/topic/Group.20add.20members.20dropdown/near/1952902
to check more about the migration plan for which this is the last step.
Fixes#25942.
Users with permission to manage the group (either on the group level or
realm level) should be able to add members to the group without being
present in can_add_members_group.
Earlier, only public data export was possible via `POST /export/realm`
endpoint. This commit adds support to create full data export with
member consent via that endpoint.
Also, this adds a 'export_type' parameter to the dictionaries
in `realm_export` event type and `GET /export/realm` response.
Fixes part of #31201.
`$(".buddy-list-subsection-header").children()` has length more often
than I had thought. Using the narrow filter is more direct way of
managing this state.
We previously auto-mocked this out of expediency, but that made it
impossible to test anything that uses the Zod schemata in the same
module.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This should work because all the events are either `change` events or
`click` events on elements without children. This change is being made
to make typescript migration easier, ecause we can type `this` more
easily than `e.target`.
On a fresh render of a narrow if the view doesn't scroll,
`update_sticky_recipient_headers` is not called. So, we need call
it after we have scrolled to the message we want to select.
Previously, only spaces were used as word separators when searching
for topics. This meant that searching for "support" would not find a
topic named "topic_support" or "topic/support," which could lead to
unexpected results.
To address this, hyphen (-), underscore (_), colon (:), and slash (/)
have been added as additional word separators for topic filtering in
the left sidebar, as these characters are commonly used as separators
in topic names.
Fixes: #31844
Before, the message reactions section along with the add reaction button
was being rendered for every message even when there were no reactions
present - this led to additional DOM cost.
This commit adds the message reactions section only when there is
at least a single reaction on the message, and follows up with a cleanup
of the message reactions section when there are no reactions.
Fixes#31137.
Co-authored-by: Anmol-dev45 <basnetanmol2020@gmail.com>
Previously [{operator: "topic", operand: "one\xa0two"}] would be
unparsed to "topic:one\xa0two" which parses as [{operator: "topic",
operand: "one"}, {operator: "search", operand: "two"}], leading to
exceptions in the search pill system.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, the "stream_topic_history" used to store unacked float
message ids as well in its "max_message_id" of stream and
"message_id" of topic histories.
This commit updates it to rather store only the acked message ids
here, and rather use the "echo_state" module so as to look up
for unacked messages in case of looking for recent topics, or
max message id in functions.
Previously, when `insert_local_message` was called, the
data structures in the `echo_state` are updated with the new
local messages after calling `insert_new_message`. This would
update the stream sidebar before even updating the `echo_state`
with the new local messages.
This commit introduces `track_local_message`, which basically
updates the `echo_state` data structures with the local
message before actually updating the stream sidebar.
This is a preparatory commit to update stream_topic_history
to only contain acked message ids.
This commit refactors the `ensure_channel_topic_terms` of filter.ts.
Previously, this method used to add channel and topic terms, with
operands as placeholders in case the `with` narrow doesn't have
channel-topic terms.
This commit updates it to rather correct the narrow with the right
terms in case the channel-topic terms are missing in the `with`
narrow, but leave it as it is in case the channel-topic terms are
present, so that it can later be corrected if the channel-topic
terms are not pointing to the right conversation.
This was causing a bug where the participants weren't necessarily
all getting rendered, specifically when there were many subscribers
to a channel, because we render users in batches as buddy list
scrolls, and those users would only show up after some scrolling.
This fix makes sure we always load the participants first.
We create an unnamed user group with just the group creator as it's
member when trying to set the default. The pattern I've followed across
most of the acting_user additions is to just put the user declared
somewhere before the check_add_user_group and see if the test passes.
If it does not, then I'll look at what kind of user it needs to be set
to `acting_user`.
We also add the exception for the group creator to be able to edit their
group in this commit. This exception was added in the backend in earlier
commits.
This is helpful for when a user wants to delete multiple pills
in a row, now that a pill needs to be highlighted before it can
be deleted.
It makes more sense intuitively for the previous pill to be selected
after backspace, since the direction of deletion is backwards. We
still potentially focus next() if there is no previous pill, which
is most helpful when the input element has no more pills left, since
this focuses the text field.
Select the pill on the first backspace and delete the whole pill on
the second backspace. If the pill is already highlighted from
left-pressing, then backspace would delete it right away.
We're making this change because it can be quite annoying to
re-type out a pill that's accidentally deleted, and users might
think pills are editable and accidentally delete the whole thing
with a backspace stroke.