We now pass group in functions called while handling group update
events, instead of fetching the groups in those function as we
will need the old setting value in future commits.
Tests for testing user group events does not stub "user_groups"
module anymore as it is mainly used to handle data and it is
easy to test the events without stubbing them.
Zod schema and type for realm level group settings is moved
to group_permission_settings.ts as we would define types for
stream and group settings there and the change would also help
in avoiding import cycles in further commits.
Earlier, tooltip in left sidebar views had only the navigation list
title shown inside it.
This commit adds more information to the tooltip by including their
respective counts.
Fixes: zulip#25901.
Co-authored-by: ecxtacy <dc.dhruvchouhan@gmail.com>
Earlier, left sidebar navigation had two separate tooltip logic to
handle the same tooltip template.
This commit refactors it to use a single tooltip logic for the left
sidebar navigation.
While adding a new reaction, we create a new JQuery element
called "message_reaction_container" and append it to the
view to display the emoji.
Previously, when the reaction count became zero for an emoji,
we used to just remove the emoji but not the JQuery element
mentioned above, requiring a reload to remove it. This
inconsistency introduced a bug in the UI. causing unwanted
spaces between emojies as this element used to get accumulated.
This commit resolves the bug by introducing logic to remove
reaction containers with no reactions.
Fixes: #32983
This ensures that using `^V` pastes the content from excel as
an image.
To get normal text in a formatted manner one can use
`^⇧V`.
The earlier conditions in `is_single_image` caused
the classification to fail in case of Excel pasted
content, which is why we check for the for the XML
namespaces associated with Microsoft in the pasted
HTML.
Fixes#32968.
The names of helpers have evolved over time.
I add a few, and I remove `common_subscribe_to_streams`,
since most tests just want the simpler subscribe.
Note that `subscribe`, while not full stack, does
excercise `bulk_add_subscriptions`. So there is no
real danger of having unrealistic test data.
Almost all of our uses of `common_subscribe_to_streams`
are in test_subs.py, so it's already effectively
our policy to use subscribe in most cases. And
test_subs does more than a thorough job of actually
exercising the API.
The original mocking example now uses time_machine, so I slimmed
down a lot of its comments, and then I created another
mocking example so that we still touch on mocking in
terms of mock.patch.
The new method reinforces the pattern of testing both the
sad path and happy path inside the same test.
Fixes#33156.
If the stream is set to on the private settings for privacy, we add a
parenthesis text `must be subscribed`.
We had to use JS to change the string since just having a conditional in
the handlebars template would not ensure that the parenthesis text
appears or disappears on changing the value.
When using `position` to get the scroll offset, it uses `offsetParent`
to calculate the offset which is not necessary the scroll container.
To account for this case, we use `offset` to correctly calculate
the position of element relative to the document.
The last topic is not visible in left sidebar in zoomed_in state.
This is due to height of `views-label-container` not being accounted
for when calculating scrollable height of the topics list.
There is no reason to show "Everyone on internet" group in
group members, stream subscribers, silent mention and DM
recipient typeaheads since specatators cannot be added to
groups or streams, cannot be involved in DMs and cannot be
mentioned.
A 16px conversion at 16px/1em is unnecessary, and there are no
other font-size declarations in the area. So the base font-size
should be inherited as expected, allowing the button icons to
scale.
This logic is superfluous, as action buttons are hidden unless
hovered, and when hovered, the `display: none` this sets is
overridden anyway.
Additionally, removing this avoids interference with the flexbox
presenting the action icons, which was causing elements in the
sender line (sender, as well as the timestamp) to visibly shift
out of place when editing the topic, only to see the layout
corrected upon hovering in the action-button area.
We have an increasing number of design discussions about mobile
these days (which is great), and that means I've started to
regularly point people to this page -- particularly the section
"Guidelines for code contributors" -- as part of pointing them to
the #mobile-design channel to ask a design question.
In that context it seems confusing that it only talks about #design
and not #mobile-design. We do mention the latter elsewhere on the
page, but I still feel I have to explain the discrepancy when
pointing to this section. Fix it here instead.
This introduces to our docs the concept of "a design channel",
meaning #design and #mobile-design and sometimes #zulip-terminal.
When `message_row`s can be stacked on top of each other if draft
or scheduled messages overlay is open. To avoid selecting
message from them, we filter them out.
This commit adds support to display `realm_empty_topic_display_name`
value (in italics) in the search suggestions & search input pills
for topics having the actual value of empty string.
We show `realm_empty_topic_display_name` for empty string
topics in the SETTINGS/TOPICS table.
This commit makes it possible for users to search for
the `realm_empty_topic_display_name` value to filter out empty
string topics.
We show `realm_empty_topic_display_name` for empty string
topics in the inbox view.
This commit makes it possible for users to search for
the `realm_empty_topic_display_name` value to filter out empty
string topics.
We show `realm_empty_topic_display_name` for empty string topics
in the recent conversations view.
This commit makes it possible for users to search for
the `realm_empty_topic_display_name` value to filter out empty
string topics.
This commit unifies translation strings for reply button label
to reduce translation effort.
Both the `has_empty_string_topic` and other cases now use a single
"Message <z-recipient-label></z-recipient-label>"`, with dynamic
content passed appropriately.
This commit is a part of the work to support empty
string as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to
`GET /users/me/{stream_id}/topics` endpoint to decide
whether the topic names in the fetched `topics` array
can be empty strings.
If False, the topic names in the fetched response will
have the value of `realm_empty_topic_display_name` field
in `POST /register` response replacing "".
Fixes part of #23291.
Fixes#32706.
A user with permission to invite users should be able to subscribe users
to any of the default streams whether they have the permission to do so
or not for each of those default streams or not. This should only happen
in the invite code path, and not the subscribe code path.
This commit also adds the ability to pick and chose default streams if
you do not have the permission to subscribe to any other channels.
Before this, if you did not have the permission to subscribe any other
channels, only the checkbox to subscribe to all the default streams at
once was available to you.
For the stream pill typeahead, we don't show streams that the user
cannot subscribe other users to. For more details, see
https://chat.zulip.org/#narrow/channel/101-design/topic/can.20subscribe.20other.20users.20permission.20invite
We were just checking the realm wide setting before to determine whether
to show the subscribe widget or not. `can_subscribe` of
`get_streams_for_user` had already been using `can_subscribe_others`,
so it was aleady following the new logic to determiner whether a user
can subscribe others to a channel. So there was no change needed there.
We were using the realm wide permsision to determiner whether to show
the widget or not, but now we use the number of subscribe-able
unsubscribed channels to determine whether the widget should be shown
or not.
Previously, we only used to have a realm wide setting on whether a user
can add subscribers to a channel. In that case, if the user was not
allowed to add subscribers inspite of having the realm wide permissions,
that would mean it's a private channel that they don't have access to.
After adding the per-channel setting to add subscribers, that is no
longer the case and the tooltip message has been made more generic to
reflect that.
