This is a follow-up to the previous commit, which updated the links in
docs and comments. This commit updates those links that are part of
some code.
This commit is a part of the effort to rename stream to channel.
Updates all the https://chat.zulip.org/#narrow/stream/ links in the
docs and comments to use the new /channel/ path. All these links are
for documentation/reference purposes only and thus, can be bulk-updated.
This commit is a part of the effort to rename stream to channel.
* `.container` class is only used in `/activity/support` and
`/activity/remote/support` pages. It is also used in emails but
it has its own CSS.
* Since the CSS applied is localized and looks good, we just
move the CSS relevant to us to `activity.css` which is used
by both of these pages.
* Searched `"container"`, ` container `, `"container ` and
` container"` to look for the uses of this class.
This commit, adds the `.popover-menu-tab-group` class to the tab pickers
that appear together with the other popover menu options and thus
need to match their spacing and margins for a uniform look.
This removes the need to maintain a cluttered list of tab pickers that
need to be styled as such in the `popovers.css` file.
As part of the popover menu redesign, this updates the topic visibility
popover to use the new "popover-menu" popover theme and improves
accessibility by using appropriate ARIA attributes.
This also moves the `:focus-visible` CSS rule to apply to any tab
picker in a popover, removing the need to explicitly add it to each
tab picker.
Fixes part of #28699.
Earlier, when a user was in /near/ topic or dm view, on sending
message in the same conversation we were incorrectly displaying
the 'jump to sent message' banner.
This commit fixes the incorrect behavior.
Fixes#30341.
Earlier, when a user was in /near/ topic or dm view, the scheduled
message indicator was missing in the conversation.
This commit fixes the incorrect behavior.
Currently we send a notification to the topic if it has been resolved
or unresolved even if there is an immediate event of resolving and
then unresolving or vice-versa. This adds a setting of
RESOLVE_TOPIC_UNDO_GRACE_PERIOD_SECONDS under which if a topic has
been unresolved after being resolved immediately and the last message
was the notification of resolving, then delete the last message and
don't send a new notification and vice-versa.
We use the new message.type field to precisely identify relevant
messages.
Fixes#19181.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
This commit removes create_public_stream_policy setting
since public channel creation permissions are now handled
by group-based setting.
We still pass "realm_create_public_stream_policy" in
"/register" response though for older clients with its
value being set depending on the value of group based
setting. If we cannot set its value to an appropriate
enum corresponding to the group setting, then we set
it to "Members only" considering that server will not
allow the users without permissions to create public
channels but the client can make sure that UI is
available to the users who have permission.
Create has:reaction search operator and search suggestions.
Create sidebar view for the user to view their messages that
have reactions using has:reaction sender:me operators.
Add custom heading for the view and tooltip in the sidebar.
Add documentation for the new operator.
Fixes: #27328.
While sending multiple messages to different recipients in
'message_basic_tests', we were facing flaky test failure.
The reason being now we jump to the conversation where message
was sent & that was resulting in calls to the
'wait_for_fully_processed_message' function as 'outside_view'
was not correctly set.
Precisely, the call to 'wait_for_fully_processed_message' uses
zulip_test.current_msg_list which won't remain correct when
the sender is narrowed to different views on sending messages
to different recipients in succession.
Organize and sort the options in tsconfig.json according to the way
they’re listed at https://www.typescriptlang.org/tsconfig/.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This was a bug, where in the realm.presence_disabled (synonymous to
being a zephyr mirror realm) case we would return None. We have decided
on the convention of using only integers here, and -1 representing lack
of data.
Note: This involves adding presence info of unknown users to the
presence data.
With some small tweaks, we can just add the info to the presence data
structures, just making sure the buddy list correctly skips those
entries and that we redraw the user in the case where the user creation
event arrives after the presence polling loop.