While creating a pronouns type field, "display_in_profile_summary"
checkbox is checked by default for "Pronouns" type field if the
limit is not reached.
Fixes#21271.
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 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>
Previously, content box was focused inspite of it being disabled in case
when only stream editing was allowed. Now we instead focus on the stream
down.
Instead of having a separate field, we can use in if condition on
view_source_menu_item itself to determine whether to show the view
source option or not.
Previously "Move message" option was not shown when content editing
was also allowed and also when only moving messaages between streams
was allowed but not topic edits.
Now we show "Move message" option when editing topics or moving
messages between streams is allowed irrespective of whether content
editing is allowed or not.
Split the View source / Move message option into two menu options that
take you to the same UI: Move message and View message source.
Previously, it was confusing to have this double option,
and hard to parse it at a glance.
-View message source uses the current icon.
-Move message uses the arrows icon from the Move topic menu option.
-New option order: (1) Move message, (2) Quote and reply or forward,
(3) View message source.
Also remove the "Topic editing only" and "View source" text on the
bottom right of the message edit UI along with the tooltips. Only
the timer text is shown (along with tooltip) when content editing
is allowed.
This commit renames Edit to Edit message and Collapse to Collapse message
for better readability and to match the Delete message and
Copy link to message options.
Adds a section to the top of the stats page for organization
summary statistics. Also, adds the first two statistics to that
section for total users in the organization and users that have
been active in the past 15 days.
This label is unnecessary and creates the potential for an incorrect
assumption that it's only useful for testing, when in fact it's a
reasonable configuration overall.
There are cases where we add some text in italics inside parens along
with the label in checkbox settings.
This commit adds option to settings_checkbox template so that we can
directly use it and not require to duplicate the settings_checkbox
code and thus we now use settings_checkbox template for
enable_read_receipts setting.
Removes a click handler in `populate_messages_sent_by_client` for
anchor links that start with a hash.
I think this goes back to when there was a sidebar navigation on
the stats page, which no longer exists. The only anchor link in
the current html is to the help center documentation and not part
of the Plotly charts.
I found a highly reproducible bug using the "Mark as unread" feature,
which triggers a rerender via message_list.rerender_view().
The reproducer was as follows:
* Navigate to a narrow by going to All messages and using the `S` hotkey.
* Mark as unread to mark several messages as unread in that view.
* Notice that the message that had been selected in home_message_list
is immediately marked as read again.
What was happening is that the reselect_selected_id call for
message_lists.home (All messages) was incorrectly re-marking the
currently selected message as read, even though (1) that view was not
visible and (2) this was an internal rendering change that could not
be the first time the message was selected.
Because only the current message_list has marking messages as read
blocked, it's still able to mark the currently selected message as
read.
All the callers of reselect_selected_id are internal rendering code
paths that are not intended to be user-visible; as a result, they
should not change the unread state either.
The bug fixed here is a potential root cause of #16986, but I haven't
had a chacne to confirm it.
redo_selection and reselect_selected_id did the same thing: Reselect
the currently selected message as a result of internal rendering. I
combine the useful features of both -- not crashing if no message is
selected (id -1) and passing the `from_rendering` option, to avoid
potentially triggering an additional rerender.
We now first convert the element value to number using "Number()"
function and then call parseFloat in parse_time_limit function.
If we do not do so and the input element contains something like
"24a", it will be converted to 24 after parseFloat and will result
in an unexpected behavior where the save-discard widget will not
appear if the custom value input is changed from "24" to "24a",
since the value is considered as same as before.
But now "24a" will return NaN and save-discard widget will
appear with save button disabled.
Previously, typing something like "24aa" in message edit limit
custom input box would not disable the "Save changes" button
and clicking on it would set the limit to 24 minutes because
"24aa" was parsed to 24 by parseInt which is a valid value.
We now fix this to first convert the input to number using
"Number()" function and then use parseInt. "Number()" function
returns NaN for input like "24a" and other inputs containing
alphabet characters and thus it is considered as invalid value
and "Save changes" button is disabled.
Previously realm-level default of email notification batching period
setting was handled as a special case in populate_data_for_request.
But now we have added some functions to handle time limit settings and
this commit changes the email notification batching setting to be
handled similarly.
This commit renames get_message_edit_or_delete_limit_setting_value
function to get_time_limit_setting_value, so that we can use the
same function to get value for email notification batching setting
value.
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 extracts a function to show or hide the custom
input of message edit and delete limit setting and to set
the initial value of custom input while showing it.
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.
The implementation is simple, we just check if the
the message sender is a notification bot to decide if we
should show the read receipts list.
We also update the modal content styling to match the padding at the
top of the modal.
Fixes#22905
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.
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.
As of 297379029d, the data for the current user's buddy list
row no longer uses the '(unavailable)' or '(you)' text generated by
`buddy_data.get_my_user_status`. This commit removes the function
and related frontend tests.
Remaining instances of `my_user_status` in the codebase are related
to the CSS rule in `right_sidebar.css`, which is still relevant.
Prep commit for transitioning from 'unavailable' user status
feature to 'invisible mode' user presence feature.
Displaying unsubscribe button on bots full profile modal, allowing bot
owners to ubsubscribe their bots from streams.
Admins can also unsubscribe any bot from any subscribed streams from
bots full profile modal.
Fixes part of: #21402
This commit can display a full user profile modal for bots too,
by clicking on "View Full Profile" in the profile info popover
same as normal users.
Fixes part of: #21402
This commit disables the settings in "Joining the organization"
subsection for admins as they can be changed by only owners.
We also move the tooltip mentioning "Only owners can change..."
to the subsection heading.
While editing custom profile fields, when user delete option(s) of
select type profile field, display that deleted option(s) in delete
option confirmation modal.
Follow-up: 21878
Since we are updating the help center documentation to use `<kbd>`
HTML elements when documenting keyboard keys and shortcuts, we no
longer need to support `<code>` HTML elements in
`adjust_mac_shortcuts`.
Updates references to keyboard keys in the help center docs to use
`<kbd>` HTML elements, which also means updating them to be as the
key would appear on a keyboard.
Previously, uppercase and lowercase letters were used to indicate
when/if the `Shift` key was being used, and even that was not
consistent throughout the documentation.
For CSS styling, adds a similar rule for `<kbd>` elements that is
used in `/static/styles/app_components.css`. And updates the CSS
class used in `/static/js/portico/help.js` for `adjust_mac_shortcuts`
accordingly.
Also, takes advantage of revising these pages for making small
updates for current help center documentation practices.
Disable "External account type" select field from External account type
profile field edit form, doing it because this select field is not
editable and it is incorrectly looks like editable.
Until now, whenever typeahead autocompleted the spoiler syntax, there
was no indication if and how a visible header to the hidden content
could be added.
Now when autocompleting, the word "Header" is added as a placeholder
and highlighted, hinting at the format.
Fixes: #20868.
This makes the implementation more readable, and also dependant only
on the `highlight` object, not the detail that previously only slash
commands, which have an `item.placeholder`, used this code path.
This is part of redesigning messages (#22059). This commit adds
classnames to messages with mentions, differentiating direct mentions
from wildcard mentions from usergroup mentions, and this set us up
for a future commit where we'll have those different kinds of messages
be displayed in different colors.
Added a user_list_style personal user setting to the bottom of
Settings > Display settings > Theme section which controls the look
of the right sidebar user list.
The radio button UI includes a preview of what the styles look like.
The setting is intended to eventually have 3 possible values: COMPACT,
WITH_STATUS and WITH_AVATAR; the final value is not yet implemented.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
There will be one more follow up commit to this, that will
add support for editing memberships of user groups and will
complete preliminary version for user group edit settings.
Follw up for #22214.
In 7b4f7b4a85, we replaced
do_settings_change the dialog_widget.send_api_request.
When 0a278c39d2 was rebased past that
change, the merge conflict was resolved incorrectly, resulting in
duplicate API requests.
Currently when a user does not have the permission to edit the topic/content
of a message, the edit UI/view source UI correctly shows a greyed
out topic/message-content input field, however these fields incorrectly have a
click behavior, so to fix this we now would want to use `disabled` prop instead
of `readonly` attribute as `readonly` controls can still function and are still
focusable whereas disabled controls can not receive focus and are unclickable.
Fixes#22565.
Note that we do not include the situation when no one
has read the message yet. Though the ICU MessageFormat
has the capability to do that, that case has already
been handled in the if block.
Fixes#22830.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Sahil Batra
Aman Agrawal
evykassirer
Tim Abbott
Zixuan James Li
Akarsh Jain
Ganesh Pawar
Yogesh Sirsat
Lauryn Menard
Steve Howell
Riken Shah
Mateusz Mandera
Purushottam Tiwari
Anders Kaseorg
N-Shar-ma
Raghav Luthra
Ganesh Pawar
rixant
jai2201
Khushiyant