This provides a hook for users to get to these /help/ pages, which contain
details on exactly how these notifications/settings work, as well as
troubleshooting advice.
Fixes: #23369.
Instead of using "these people", we use "these users".
Note that the "pm-with" single user case has already been updated
to show the user's full name instead of "this person".
Due to incorrect heights set for user-group creation and stream
creation body we had a UI bug because of which bottom part of
user group and stream creation forms were slightly visible
through the bottom.
It was due to somewhat fussy css height rules and incorrect
height calculations for that UI.
This function is only called to calculate the size of stream and
user list. Using 250px as minimum height for these blocks gives
them enough space to be usable regardless of their height ratio.
If the buddy list is displayed in the left sidebar, height of
both these blocks needs to be changed to accommodate for the
changes.
The fixes the bug that stream list and user list don't fill
left sidebar and have 80px height regardless of viewport height.
When building search suggestions for stream topics, instead of
assuming that the user has access to the stream's topic history
from the server, we check whether the user has access to the
stream's topics.
Updates the check in compose validate for the organization's
policy on sending private messages to use the code/value in
settings_config, instead of the number value.
Private messages between a user and a bot are not restricted by
the organization's policy setting for sending private messages.
So, for the empty banner text, we set the default title for
a single bot for the "pm-with" narrow.
Group private messages that include a bot are restricted by
this policy setting, so those messages stay the same.
Also, since bot's aren't people, we update the text for valid
"pm-with", "sender" and "group-pm-with" operands to include the
user's full name in the title.
When there are multiple people in the "pm-with" narrow, we still
send a generic "these people" message instead of listing all the
users in the narrow.
Finally, we make the default message end in a period instead of
an exclamation mark.
For narrows that focus on private messages ("is:private", "pm-with",
"group-pm-with"), we want to check the organization private message
policy and set an empty narrow title that matches that policy.
For these narrows with invalid users, we prioritize that message
for the empty narrow title, instead of the private message policy
message.
Fixes#21889.
A user could trigger a "pm-with" narrow with an invalid user by moving
back/forward in the session, which would trigger the compose box to
open via a hash change. Updates the check to pass in any "pm-with"
narrow with an invalid user.
Also, if the compose box was active/started in the previous view, but
without any content, then we want to actively cancel/close it in the
invalid user "pm-with" narrow.
If an organization has disabled sending private messages, we do not
want to load the compose box automatically for "pm-with" narrows.
We still open the compose box for private messages narrows with a
single bot user as this is not limited by this organization setting.
Also, if the compose box was active/started in a narrow with a bot
user, but had no content, then we want to close/cancel that in a
new narrow with a person or group.
Fixes#23332
Check if col we are trying to focus exists for the row inside
`set_table_focus`.
We call `revive_current_focus` after `topics_widget` is defined
since it can be used inside it.
Fixes#23331
Combine checks for last row between `vim_dowm` and `down_arrow`.
Check for the presence of unread counter in `set_table_focus`
directly so that it can be used in other cases as well. This is
especially useful when marking the last row in the table as read.
We used to hide and show topic rows in the DOM when topics are
updated. This resulted in incorrect calculations in the length of
visible topics. As a consequence, focus is sometimes set to hidden topic.
Removing hidden topics from DOM helps us keep
the calculations correct.
The fixes bugs related to focus being lost when trying to mute
or mark as read the last row.
Instead of topic filter box being a part of the list when keeps
updating, we move it out and fix its position.
This should reduce rendering time of topics list and provide
a smoother experience to users when waiting for topics list to
load.
This lets us provide a hook to where we've written some advice both on
what makes a good stream description, and also what Markdown formatting
is supported there.
Fixes#23376.
In the message actions popover menu, adds an additional check for
whether the mark as unread option should be displayed based on if
the message is a stream message and if the user is subscribed to
the message's stream.
The previous check looked at whether the settings overlay as a whole
was open, not whether the specific panel we're going to update was
rendered.
The other code paths calling from server_events_dispatch into this
module already correctly check meta.loaded.
We added this logging statement in
8d33a62eca, and we now have the data to
suggest this will happen in normal operation.
I left this as a blueslip.log, since it may be useful to see in the
leadup to another exception.
The message we are trying to remove from unread mentions might not
have been fetched locally.
Fortunately, the `unread_topic_counter` data structure is designed to
support exactly this kind of lookup.
This way, if the maintainer isn't able to update `main`,
the push doesn't add the shared-VERSION tag either.
That avoids ending up with a tag that potentially doesn't
get included in the history of the main branch.
The Git docs warn that servers might or might not support this
feature, but GitHub does -- indeed they boasted about it when it
first came out, in Git 2.4 back in 2015:
https://github.blog/2015-04-30-git-2-4-atomic-pushes-push-to-deploy-and-more/
The emoji matcher uses this property in is_unicode_emoji.
It doesn't quite make sense to be talking about "reaction types"
here -- we might use this for a message-reactions UI, but we might
just as reasonably use it for emoji UI in message composing. Ah,
well: I guess that's just a bit of messiness that we can deal with.
When "group-pm-with" is the first operator and setting an empty
narrow banner, check that the operand matches a user and set the
title based on whether the user exists or not.
Because "group-pm-with" is not a common search operator, instead of
setting a specialized title in the browser and tab, just use the
default title, "Search results".
Moves the three images of the web-app on different operating
systems (Mac, Ubuntu and Windows) to the same directory as
the two mobile-app screenshots, `/static/images/app-screenshots/`.
All five images are referenced in `static/js/landing-page.js`.
So that we can stop using Tim's photo for tests, adds an open
license profile picture to use instead.
Updates tests that used `tim.png` to use the new example profile
picture, which is located in `static/images/test-images/avatars/`.
Creates `static/images/authentication_backends` directory for icons
of backend authentication methods, which are used on the log-in page.
And updates the example documentation in the API `/server_settings`
endpoint.
Fixes#23273
Removed height restriction to allow the box to grow when text wraps
to the next line.
Aligned wrapped lines to the text in the first line instead of the
icon.
0.5 opacity felt too light; it made these appear similar in color to
muted streams, not as the intended grey text. This opacity reduction
is only applied in dark theme to sidebar titles.
This makes each of the call sites more straightforward and
transparent. In `query_matches_person` it also opens up further
simplifications, which we'll make next.
Since we're now exporting `query_matches_string` from this
shared module, we write its type in the `.js.flow` file.
Fixes#22911
`Back to streams`, stream name and filter topics are all sticky
now and their color changes based on which filter is active and
the currently applied theme.
Updates the `filter.get_title` logic to return the list of users
for narrows that include the pm_with and near operators. That way
the browser/tab title remains the same for these views.
Previously, when you clicked the confirmation button in a
dialog_widget, we'd display a loading spinner on top of an ugly grey
button background.
Remove the ugly grey background color, while making sure the loading
spinner inside the button looks good and doesn't resize the button.
Fixes: #22002
This change is made so that we are not accessing the global page_params
directly. Note that we also rename unread_msgs to params to match other
modules that follow this pattern.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This adds a get_unread_message_count helper that returns the size of
unread_messages and replaces the usage of page_param.unread_msgs.count
elsewhere in the codebase.
Fixes#23334.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This setting provides a more ergonomic experience when viewing a
message where only a small number of emoji reactions are present; you
no longer need to hover over the reaction to see who reacted, which is
often quite important to understanding what it means.
We added this setting (visible in the development environment only,
and implemented on mobile) a few months ago; so to complete this
feature, we just need to add the frontend rendering/live update logic
and publish it.
As documented in the code comments, the current rule is "messages with
3 or fewer reactions" for which messages will display the names of the
users reacting.
The previous set_reaction_count API made sense when the display of a
given reaction was a pure function of its data. However, we will soon
be making it a function of the total number of reactions on the
message.
Thus, view functions to update reaction display now need to call a
shared update_vote_text_on_message function in all code paths, even
code paths like "add the first vote for a reaction" and "remove the
sole vote of a reaction" which previously did not need to call
set_reaction_count.
Fixes#20890.
We may want to rename clean_reactions to something else, but the name
`r` is pretty confusing for an object that isn't a single reaction,
but instead an object detailing all the reactions on a message.
The blue font color on the vote_text beside the reactions in
light mode made it seem like a link which it's not, so it has
been changed to regular font color.
We preserve the blue font color on hover, matching the add-reaction
button.
This fixes a bug where in narrow windows, long vote_text could extend
beyond the body of the reaction's allocated area.
It also provides a matching right margin around the count/name inside
the reaction pill, which looks better when we have strings inside them.
Follow-up to commit 22a5d008c1.
The new display setting introduced in above commit was not registered
properly and enabling/disabling it from Organization settings > Default
user settings did not display a "Save/Discard" widget. This has been
fixed by modifying the `settings_org.get_subsection_property_elements`
function.
Since stream header is now sticky, we need to reduce it's height
when calculation position of the element we want to scroll into view
so that it doesn't hide under the sticky header.
This commit introduces the change of rendering private messages
section as collapsible, whose data-fetching logic came with zulip#21357.
We now have separated out `Private messages` from `top_left_corner`
section and shifted it below the `global_filters` in a different
separate section along with stream list with common scroll bar
in left-sidebar.
The new PM section will be opened by-default on loading the page
and will have a toggle-icon in its header, clicking on which makes the
section collapse/expand accordingly.
In default view, only recent 5 PM threads would be shown
and would append the active conversation as the 6th one at last
if not present in those 5, similar to how topics list work.
In PM section with unreads, a maximum of 8 conversations
would be shown and rest of them would be hidden behind
the 'more conversations' li-item, clicking on which takes
to the zoomedIn view of PM section where all the present
PM threads would be visible and rest of the sections of left-sidebar
will get collapsed.
Fixes#20870.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Dropped text "(Message sent when you were not subscribed)" for
historical messages in the three-dot message menu.
This information was already available via the "You subscribed" type
divider lines, which were added about the same time back in 2013, and
this text feels somewhat ugly.
Also removed the historical field from the args object that is
passed to the template, as this is not used anymore.
Fixes#23198.
Updates the `filter.get_title` logic to return the stream name for
narrows that include the stream, topic and near operators. That
way the browser/tab title remains the same for these views, which
have a particular scroll offset.
Removes call to reset_compose_message_max_height when clicking on
the markdown preview button, which due to the `#compose` div element
momentarily shrinking to be empty, caused the calculation of the
max-height to grow larger on each click.
Also refactors reset_compose_message_max_height to use the height
from `getBoundingClientRect`, which defaults to zero when empty.
And fixes a small discrepancy in how max-height is applied to
a div element vs a textarea element, so that the visible height
doesn't change between the preview and write modes in the compose
box.
Fixes#23277.
This gives us some time to render and fetch data before allowing
user to start using hotkeys. It avoids error being thrown when
hotkeys are used when the app is still loading.
Updates the hash used for the recent conversations view to be
"#recent" instead of "#recent_topics".
We will need to keep the logic for handling "#recent_topics"
permanently because users potentially have messages from
Welcome Bot with links to that hash.
Including "recent_topics" as a web_public_allowed_hash in
hash_util.js can be changed once self-hosted servers cannot
upgrade directly to Zulip 5.x from the current version.
Fixes#23132.
The resize handler is a somewhat expensive operation, which we'd like
to avoid when processing the receipt of new messages. It's also
unclear why it would be necesssary; bottom_whitespace is fixed in
size, and the sidebars.
It should be very rare to discover new unread messages during a
message_fetch call. This can potentially happen due to races (fetching
just as a new message arrives), but it shouldn't be the common case.
Previously, we would trigger a full rerender of all UI displaying
unread messages every time a bulk message fetch operation returned
(including every time one narrowed), regardless of whether any actual
state had changed.
Fix this by actually checking if we discovered any new unread messages.
There's no reason that opening left sidebar popovers should require
the app to recalculate the size of any of its components; popovers are
drawn on top of the rest of the UI in any case.
This appears to have been added in
9ed05a1f85 as part of prototyping the
left side user list feature.
This was likely introduced in error in
fd66d9f70336b2bdbbffb1bf13402516b9920682; it is a duplicate of
show_userlist_sidebar, which, in contrast is actually called.
Because we can count on the unread.js data structures to be correct,
we no longer need this legacy code that tries to re-process all
messages the client has cached for whether any are present in the
target stream and marked as unread.
It's not clear we need this at all, since the current Zulip server
will mark all messages as read when unsubscribing from a stream, but
having this call protects us from future bugs should that behavior
change.
This cleanup also revealed a possible bug, where we would fail to
update global unread counts properly when unsubscribing from a stream
until the deferred_work queue processor sends us the
update_message_flags event associated with that change.
The previous invocation message_util.do_unread_count_updates dates
from a time when `unread.js` did have any data beyond what full
message objects were present in the client, and thus we needed to
recalculate everything from those message objects when muting state
was changed.
With the modern unread.js data structures, all that's required is a
full recalculation/rerender via this function.
We change the "pm-with" and "sender" narrow urls
to be of "{user-id}-{encoded_name}" form instead
of using email. This change improves performance
of changing between PM views since parseOneAddress
function was slow and we remove its usage now by
using name instead of email.
The name is encoded such that the characters that
would be encoded by the browsers are replaced by
"-".