The reason utcToZonedTime would return an invalid Date (i.e. ‘new
Date(NaN)’) is because we passed in an invalid timezone. Fix the
comments and tests to reflect this; remove unnecessary mocking and the
misleading ‘instanceof Date’ check.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
`current_date` being invalid here could result in `user card`
not being displayed to users. So, it is important to verify that
the date is valid so that we don't run into any errors.
This fixes (unverified) an issue where user card was not being
displayed to some users on Zulip Desktop app because `current_date`
was not valid.
This commit refactors the code for realm message retention
setting which will help us in reusing some code when adding
save-discard widget for stream settings in further commits.
Following changes have been done in this commit -
- Renamed the "retain_for_period" option to "custom_period"
and "retain_forever" option to "unlimited" to match with
the stream settings options such that we can reuse the code.
- Updated set_message_retention_setting_dropdown such that
it can be used for stream message retention setting as well.
This commit renames the "org-subsection-parent" class used for
organization settings subsections to "settings-subsection-parent"
such that we can use same for the stream settings and avoid
duplicating code for handling save-discard widget which will be
added in future.
We passed subsection elem to get_subsection_property_elements function
in all cases except the one when calling from discard button click
handler and we passed the input elem instead in that case.
This commit changes the code to pass subsection element directly
in the discard button click handler as well such that we can use
get_subsection_property_elements function for the stream settings
code and do not find the subsection element inside the function.
Before 2017, Zulip's manage streams and settings UIs were tab in the
same pane position as our current message feed and recent topics.
That original implementation was implemented using Bootstrap tabs;
while it hasn't been in use for years, we had a bunch of stale code
related to it leftover in this module.
Fixes an issue introduced in 6b4ab21 when we started using the
user's full name for empty narrow titles in a single operator
narrow of either "pm-with", "group-pm-with" or "sender".
For these empty narrow titles, any ', & or < characters in the
user's full name are not escaped.
This commit reverts the changes for replace_syntax in 1ca4566eb2
and we again use JS replace instead of replace from text-field-edit.
We do this change because replace from text-field-edit leaves the
replaced text selected, which we don't want. This change is
temporary and we can probably use replace method from
text-field-edit once this issue is fixed in upstream.
Instead of using setInterval to call send_presence_to_server
repeatedly, we now simluate setInterval using setTimeout.
This change helps us to avoid the condition likely related to resume
from suspend, when the browser tries to catch up by running a large
number of "missed" copies of the setInterval hook, causing the server
to rate-limit the client.
Fixes#23438.
Fixes#23517.
While this feature was added to Zulip very early, it has been troubled
for most of that time; it never looked great visually, had a lot of
implementation complexity around resize.js, and has a weird model (a
setting that changes the UI only in certain window sizes).
This option is not commonly used; while a significant portion of users
have it enabled, many of them just don't use window sizes where it
actually has an effect. So it's not clear that it will be missed if
removed; we got very few bug reports when it was completely broken for
a few days after we first integrated the new left sidebar private
messages design.
Even with it no longer being broken, it does not work very well with
the addition of the new PMs section in the left sidebar. (Having two
scrollbars in the sidebar looks quite awkward.) The new private
messages section in the left sidebar also addresses some of the use
cases for always keeping the Users list always visible, even in narrow
windows.
This option is only removed from frontend for now. To make this
decision easily reversible, the backend code of this feature
is still kept.
Fixes#23284
The basic approach used by `text-area-edit` is same as we were
using, so there is no real change. There are some nice checks
in `text-area-edit` which we don't do that helps us avoid
common bugs.
This commit refactors the code for realm message retention
setting to make it more similar to code for other time-limit
realm settings. There are still separate functions for the
message retention setting but they are similar to that of
other time-limit settings and can probably help us to
deduplicate the code in future. This refactor also helps
us in reusing some code for stream message retention
setting for changes in #23013.
This commit also fixes a bug where save-discard widget
not being hidden when resetting the setting to original
value. This can only be reproduced when the original
setting value is "retain_forever".
Following changes have been done in this commit -
- Added data-setting-widget-type attribute which is set to
"message-retention-setting" similar to "time-limit" value for
message edit and delete limit settings.
- Added get_message_retention_setting_value function similar
to get_time_limit_setting_value function which is used by
get_input_element_value.
- Removed "message-retention" block from
get_complete_data_for_subsection and the message retention
setting is now added to request data in populate_data_for_request
itself using data-setting-widget-type attribute.
- Updated id and class of elements to support the above changes.
Showing section separators in the left sidebar ("Pinned streams",
"Active streams", etc.) is unnecessary when there is only one section,
and can feel confusing. We should show the separators only when there
is more than one section present.
Fixes#22843.
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".
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.
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.
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.
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.
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.
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.
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 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.
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>
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.
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.
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.
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
"-".
We should not show UI for moving locally echoed or failed messages.
For the edit/move icon in message controls -
- After 2451002, we showed "Move message" icon for locally echoed
messages when moving messages was allowed as per org permissions.
This was clearly a bug and this commit fixes it and we instead
show "View source" icon.
For "m" hotkey -
- After 2451002, pressing "m" opened "Move messages" modal for
locally echoed messages when moving messages was allowed as per
org permissions. This was clearly a bug and this commit fixes it
and pressing "m" does nothing.
For pencil icon in recipient header -
- Previously, the pencil icon was showed even if first message
below the recipient bar was locally echoed and the topic edit
failed silently with locally echoed or failed messages again
showing under old topic after reload. This commit fixes it
to hide the icon in such cases. The original behavior was
that server returned an error with not so appropriate
response.
- Note that we can only check the first message below the header
since it will be inefficient to check all the messages whether
each of them is successfully sent.
And in such cases when any of the later messages is locally
echoed, the topic edit succeeds but the locally echoed or failed
messages are shown under old topic after reload.
- The behavior is same for the "checkmark" icon for resolving
topics in the header.
For three-dot message menu -
- We don't need to do anything here since the three-dot icon
is not shown for locally echoed or failed messages.
For the "Move topic" option in topic popover in left sidebar -
- We cannot do anything here since it will be inefficient
to check all messages in the topic whether they are locally
echoed or not everytime we open the popover.
- If the first message in topic is locally echoed or a failed
message, then the id of first message of the topic returned
from server is undefined and we see an error in client while
trying to get message from that id. And if one or multiple of
the later messages is locally echoed, then only successful and
server-acked messages are moved.
Note that this cannot handle all cases like a user can use
a successfully sent message to access the topic edit UI
and then choose "change_all" and "change_later" propagate
modes. In such cases the locally echoed and failed messages
will remain in the old topic only.
We now do not test is_topic_editable function in
get_editability test for better readability and
this will be helpful when we will need to test
more cases as part of #21739.
This fixes a couple significant issues with the drafts logic:
* Previously, we would move drafts even when !going_forward_change; this
is inconsistent with the compose box logic on the previous line.
* The drafts.rename_topic() function did not handle drafts with
incomplete stream/topic fields correctly, throwing an exception in
that case; this resulted in user-visible live update problems
because code after the drafts.rename_topic call would not be
executed.
Replaces instances of "recent topics" in the web-app and documentation
to be "recent conversations".
Renames both `recent-topics.md` files in the help center to be
`recent-conversations.md` and updates/redirects links to new URL.
Does not update instances of "recent topics" in frontend code comments
and does not update the main overview changelog, for now.
Does not change case study text where "recent topics" was referenced
in a quote, but does change generic text references to be "recent
conversations".
Fixes#22984
Add an `@` icon in unread topics where user is mentioned.
We track a new set of `stream_id:topic` pairs for the unread mentions
so that recent topics instantly knows if a topic is unread and mentioned
or not.
Previously, we allowed editing topic of "no topic" message, when other
conditions were not met, only from recipient bar but it is allowed
irrespective of other condtions. This commit fixes it to show the
"Move message" option and icon for "no topic" messages irrespective
of other conditions.
Previously, NO_LONGER type was just used to display
the text in the bottom-right of message edit form
which we have removed now, so we can remove `NO_LONGER`
type now.
Sets a default value of "Search results" for complicated narrow search
views and updates logic to use `filter.get_title` as a helper to
generate better titles for some common search views.
Does not update the existing behavior for narrow searches that have
"pm-with" or "group-pm-with" operators.
Note as of this change, the default search title and titles generated
from `filter.get_title` will be translated into the user's preferred
language.
Fixes#22952.
Updates `filter.get_title` to return 'undefined' for any narrow
with a search operator. Previously it would return a title if
the search operator was paired with a common narrow, but those
results were not being used when building the message view
header and will not be used for setting the browser title.
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
When the narrow/search for a stream is undefined because either the
stream does not exist or the user is not subscribed to the private
stream, format the title that's used in the message view header to
include the stream name that was searched for.
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
Updates default title for `streams:public` narrow to be
"Messages in all public streams".
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
In `filter.get_title`, add cases for the two missing "is" operators,
"alerted" and "unread".
Prep commit for rewriting `update_narrow_title` to use
`filter.get_title` as a helper for setting browser title text.
This commit adds private messages to the Recent topics view, to make
it an all-encompassing overview of recent activity visible to the user.
We add a filter "Include PM" to toggle whether PMs should be shown in
recent topics.
Fixes#19449.
We now allow only content edit in message_edit_form which can
be opened by pencil icon in the message row, "Edit message"
option in popover and by using e hotkey.
As a result of this change, we also do not show topic and stream
edit options when using "View source" options.
We would instead support changing stream and topic from the modal
which will be opened from the "Move message" option in message
actions popover.
Previously we did not send notification for topic-only edits.
Now, we add backend support for sending notification to topic-only
edits as well.
We would add support for this in webapp in further commits since
message edit UI will be updated as well. We just make sure that no
notifications are sent when editing topic using pencil icon in
message header.
We also change the API default for moving a topic to only notify the
new location, not the old one; this matches the current defaults in
the web UI.
Includes many tests.
We also update the puppeteer tests to test only content edit as
we are going to change the UI to not allow topic editing from
message edit UI. Also fixing the existing tests to pass while
doing topic edits is somewhat complex as notification message
is also sent to new topic by default.
Fixes#21712.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
We want to be able to differentiate between the stream and the topic
in the title bar, but the current implementation displays both the
steam name and the topic name in the same way which becomes difficult
to comprehend at a glance.
In this commit, we make the following changes,
- <stream_name> to #<stream_name> (when viewing the entire stream)
- <topic_name> to #<stream_name> > <topic_name> (when viewing a topic)
These changes help us differentiate between a stream and a topic with
with a quick glance.
Fixes#22969.
Following the addition of support for custom profile fields in the
user info popovers, we redesign the popover to have a cleaner look.
* Switch top section design from centered to left-aligned.
* Move mute/unmute and manage user options behind a \vdots menu.
* Move the local time and status into a new block.
Almost all design changes ideas are from discussion on chat.zulip.org;
see "#design > pronouns in profile card" for details.
Co-authored-by: evykassirer <evy.kassirer@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Fixes#21757.
Previously the draft count would briefly increase between the action
of sending a message and the success of sending that message.
Now the draft count will only increase if the message fails to send.
We already offer this for stream messages, but had been blocked on
adding it for private messages for visual design reasons. The dark
theme had a natural place to put this, since it had a box around the
private message recipient box; but the light theme didn't.
We add a border to the light theme private message recipient box to
allow us to add the same button to private messages, and implement
that button.
Fixes#21962.
This also adds a comment noting a remaining performance bug we have in
this code path, namely fetching messages for a streams narrow will do
unnecessary work.
This script pulls from our previously custom-written emoji strings
and fills in the rest from CLDR. It also removes 4 custom emoji which
collide with some of the new CLDR names (they will now just be called
by their CLDR name).
We renamed the id from "subject" to "stream_message_recipient_topic" in
d7c2577ffb.
It is concerning that the tests are not actually failing while this id
has been wrong. The test case might have some redundant parts or is set
up incorrectly.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This cleans up "subject" from test data and variable names. No extra
change is required for this kind of change as they are only locally used
in the test cases.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This finishes up the work from 057ee6633a.
We had this "get_reload_topic" helper for user that has "topic"
encoded as "subject" from a older release. This is unlikely to cause
problem now because we no longer use "subject" for reloading since 2018.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This removes the temporary get_draft_topic helper from utils and remove
references to draft.subject.
This finishes up the work from
9861cdfeb6. Since 2018 we had stopped
referring to the "subject" property, it is considered safe to remove
this code now. It's impossible to directly upgrade to the current
release without substantial downtime for upgrading the OS, so this
logic is unlikely to provide any future benefit.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Since set_msg_edit_limit_dropdown and set_msg_delete_limit_dropdown
have almost same code except the ID of elements, we extract a common
function set_time_limit_setting and both the above functions call
this new function only.
We can use this function for topic edit limit setting which will be
added in further commits.
We now show save-discard widget on changing the message edit and delete
limit setting dropdown from any value to "Custom" only after value inside
the custom input is changed. This makes sense as the setting value is
not actually changed unless the custom input is not changed and also
makes the behavior consistent with realm-level default of notification
batching period setting.
After this change, the dropdown element and custom input element are not
considered as different setting elements for code purposes and are
treated as single setting like the realm-level default of notification
batching period setting. And thus we remove the prop-element class
from the custom input elements of these settings.
This commit changes time_limit_dropdown_values from map to
list like we have email_notifications_batching_period_values.
This change will help us in further commits for refactoring
the message edit and delete settings related code.
We change the id and name of message delete limit dropdown to
"id_realm_message_content_delete_limit_seconds" and
"realm_message_content_delete_limit_seconds" respectively.
This is a prep commit for sending only changed settings in
message editing section to the API.
We change the id and name of message edit limit dropdown to
"id_realm_message_content_edit_limit_seconds" and
"realm_message_content_edit_limit_seconds" respectively.
This is a prep commit for sending only changed settings in
message editing section to the API.
Transitions the frontend of the web app to no longer use the
user status `away` field for setting a user's activity status
to be 'unavailable' (which is now a deprecated way to access
a user's `presence_enabled` setting).
Instead we now directly use and update the user's `presence_enabled`
setting for this feature.
Renames frontend code related to the feature to `invisible_mode`
vs `away`.
We lose node test coverage in `user_status.js` because we are now
using `channel.patch` to send these user setting updates to the
server.
Removes the temporary updates to `server_events_dispatch.py` (and
related tests) made in a previous commit, since we no longer have
or need the `away_user_ids` set.
Because the web app has the capacity to update the presence_enabled
user setting directly, we need to temporarily ensure that the
user profile popover is also updated to the correct text/value.
This can be removed once the web app client transitions to use
the presence_enabled setting for the 'invisible_mode' feature.
"Add a new bot" tab from personal `settings > bots` moving this
into a modal form, so we can trigger this form from other places
too without duplicating the code.
Fixes part of #20309.
Previously, we deleted all reload tokens on each reload, which
created a race condition if there were multiple tabs open.
Now, we continue to delete tokens after using them, but if a
token is not used it is preserved for a week before being deleted.
Fixes#22832.
This renames muting.js (in `frontend_tests/node_tests`) to
user_topics.js. This file will now contain all the tests
related to the new user_topics data structure.
This extracts tests for muting users from muting.js
(in `frontend_tests/node_tests`) into a new file
muted_users.js. Now, all the tests in muting.js
are for testing muting of topics.
Custom profile fields table `CSS` changed to fit the new "Display"
column of checkboxes, checkboxes are for select/deselect custom
profile field to display in profile popover.
New option "Display in profile summary" added in create and edit
custom profile fields form, with the help of this the user can
pick max of 2 custom profile fields except for `LONG_TEXT` and
`USER` fields to display in his user profile popover.
Checkboxes will go in a disabled state, with an explanatory tooltip,
if we've already passed the limit of 2 fields with this setting
enabled.
Fixes#21215.
Displaying custom profile fields in user profile popover, as mentioned
in the issue.
In `popovers.js` filtering out only those custom profile fields, which
are not `LONG_TEXT` or `USER` fields and their values are not empty.
Custom profile fields rendering in profile popover the same way use
similar rendering logic as in the user's full profile modal.
Fixes: #21215
In #11882, the alternate tooltip text/behavior for user status
circles was removed from the implementation, but not from the
buddy list data.
This commit removes the `buddy_data.status_description` function
and related frontend tests. There are no remaining instances of
`user_circle_status` in the codebase.
Prep commit for transitioning from 'unavailable' user status
feature to 'invisible mode' user presence feature.
We now enable and disable save button when changing inputs for custom time
limit settings in change_save_button_state function only which shows or hide
the save-discard widget instead of handling them in "change" event handlers.
This fixes the bug of save button flashing to its enabled state from
disabled state before hiding after clicking on "Discard" as now button
is re-enabled only after save-discard widget is hidden and it is disabled
if required before being shown.
Note that there is still a bug for message edit and delete limit settings
where the save button flashes to enabled state when setting is changed to
the original value instead of clicking on "Discard". This bug is not present
for email notification batching setting in a follow-up PR.
This commit also renames update_save_button_state function to
enable_or_disable_save_button to avoid confusion with
change_save_button_state function.
This commit renames dropdown value for custom option for message edit
and delete limit settings to "custom_period" to make it consistent
with the value for email notification batching setting and thus
we can avoid code duplication in further commits.
Aman Agrawal
Anders Kaseorg
Sahil Batra
Ujjawal Modi
Tim Abbott
Lauryn Menard
Rixant Rokaha
Julia Bichler
evykassirer
Rohitt Vashishtha
Zixuan James Li
jai2201
Yogesh Sirsat
madrix01
Ganesh Pawar
sayamsamal
Steve Howell
Kartik Srivastava