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>
We should now rename set_muted_topics to set_user_topics as with
the new user_topic event, there will be various types of user-topic
configurations to handle other than just muting topics.
Since we are replacing muted_topics with user_topics, the web app
should now be using the user_topics page_param to construct the
muted_topics map. Also, the UI should now use the user_topic event
instead of muted_topics to handle topic updates.
This updates user_topics.js to use the new user_topics page_param to
initialize the muted topics map. This also replaces the "muted_topics"
clause in server_events_dispatch.js with a "user_topic" clause.
As we plan to move towards using `user_topics` instead of
`muted_topics`, this helper method will be used to set an
individual `user_topic` event in the corresponding data
structure in the web app.
Documents in help center `/keyboard-shortcuts` and in the app `?`
menu the shortcuts used by browsers for navigating back and forward
through the open tab's history, which are made to work in Zulip.
Also, updates `adjust_mac_shortcuts` to update the shortcut keys
for users with Mac user agents.
Fixes#18542.
As a prep-commit for updating the billing / corporate pages for
demo organizations, initialize tippy.js with a default setting
for portico pages to use in general.
Fixes#21716.
By allowing users to view drafts that are addressed to their current narrow,
we hope to help them more easily find and continue previously drafted
messages.
Previously, we cleared the preview element only when cancelling
compose, which meant the compose box would be left in an invalid
state, showing a preview from a no longer active draft, if switching
recipients with it open.
Fix this by moving the call to clear the preview state to clear_box,
which is called in both the hide_box (close compose) and change
recipient code paths for clearing compose after not having sent a
message.
Fixes#22703.
This fixes a bug in commit 513207523c
(#21284) where handle_global_notification_updates would throw an error
on wildcard_mentions_notify because our API isn’t as symmetric as it
should be.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In theory, this function should never be called when Recent Topics is
visible. But if it somehow is, ensure that we don't access
message_lists.current without first checking whether it's visible.
The original change in 5f127c85f7 was
intended to make the loop in message_lists.js not include a
potentially stale message_lists.current in the event that one is
viewing recent topics.
We revert that change and instead do the simpler thing of explicitly
checking whether we're viewing recent topics.
I was not able to prove this code was responsible for incidents this
week where all messages were marked as read while working in "Recent
topics", but is suspicious.
Likely the correct thing is to set message_lists.current to undefined
in this code path; I'm pretty sure it's an orphaned message list that
is no longer visible when viewing topics.
We were not handling hashchange for user group settings
under diffrent conditions. So this commit adds logic for
handling various diffrent cases of hashchange for user
group settings. We also take care that #groups only in
development environment.
This is preparatory commit that does basic UI set up for
user group edit in group settings overlay. This allows us to
write proper hashchange logic for user group settings overlay
under diffrent situations.
The work in this commit will be extended in further commits
to add proper UI and group edit logic.
Add support for creation of user groups using right panel
of new user group settings overlay being developed as part
of https://github.com/zulip/zulip/issues/19526.
In further commits we will add support for editing user
groups using right panel of the overlay.
This commit also introduces a minor bug related hashchange
for #groups which would be a quick fix once we have UI
for group edit on #groups overlay.
This is a preparatory commit to set up basic UI for right panel
in user group settings overlay. At this point we only ensure
the proper display of the two panels under different screen sizs.
Actual functionality for user group creation and user group
edit will be added in subsquent commits.
Dedicated overlay for user group settings is added as part of
addressing zulip#19526.
The newely added overlay is currently empty and more UI
related to settings is to be added in further commits.
A preparatory commit to have legacy user group settings logic
as we move forward to redesign the user group settings.
This is done so that current user group settings are functional
while we are working on the redesign, and also to make it clear
that most of the code in this file will be deleted and developers
should avoid spending much time on it.
We now set the value inside custom input element of message and delete
limit setting to the original setting value when hiding the input in
process of changing the setting.
This fixes the bug of the save-discard button not hiding on doing
the following changes -
- Change the setting value from Anytime (or any other option) to custom.
- The save-discard widget appears. Now write something in custom input
box.
- Then change the setting value to the original value, which in this
case can be considered Anytime as mentioned above.
The save-discard widget should be hidden after above steps because
the setting value is changed to its already set value, but it does
not without doing the changes in this commit because
check_property_changed returns true for custom input element.
The "Save changes" button was not re-enabled if the initial
setting value was "Anytime" and then setting is changed to
"Custom" (which disabled the button since input is empty) and
then followed by changing to some other option.
This commit fixes the above mentioned bug. This bug was
introduced in #21837 where we added the functionality to
disable the save button.
This is a prep commit so that we can reuse the function to enable
or disable the save button when changing the message edit and delete
setting dropdown.
On changing either one of message edit or delete limit setting
from "Any time" to "Custom", the "Save changes" button is not
enabled even after entering valid input.
We can see this bug if both the edit or delete limit setting is
set to "Anytime" initially and one of the setting is changed to
"Custom".
This is because the custom input for "Any time" case is empty even
though it is hidden and the check for disabling the button was
not checking whether the input is hidden or not.
This commit changes the code to consider the value in custom input
box only if the input is visible, i.e. the dropdown value is set to
"Custom".
This bug was introduced in #21837 where we added the functionality
to disable the save button.
This commit fixes the bug where save-discard was not hidden when message
edit or delete setting is first changed from "Anytime" to any other value
and then again to "Any time". The save-discard widget should be hidden
since the setting is value was "Any time" already.
The bug was because check_property_changed returned true for
"realm_message_content_edit_limit_minutes" and
"realm_message_content_delete_limit_minutes" for above case as value of
setting in page_params for "Any time" case is "null" and
get_input_element_value returned "undefined" as the custom input box is
empty for "Any time" case.
This bug was introduced in #21837 where we changed the input box to be
empty for "Any time" case.
When a message is deleted, if it was the only message in the topic
and it was the previously focused message in recent topics, then
the topic is no longer in the recent topics data.
In this case, we revive the focus to the adjacent message or, if it
was the last message in the view, the focus is reset to the search
bar.
Followup to commit fde9b1d366 (#22753).
(This was a misuse of “idempotent”. “Idempotent” means that
performing the request more than once in a row has the same effect as
performing it once; it says nothing about whether the response is
cacheable.)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
It’s been unused since commit 2eacc7317d
removed the only caller of abort_all and commit
ef815e9e79 removed abort_all itself.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This was added by commit 7f174213ed, and
appears to have been designed for responses that are *successful* but
falsy. Logically, these should not implicitly represent a failure to
be retried if it were.
Note from tabbott: The background is that this idempotent retry loop
was a hacky workaround for a bug we never understood but saw daily in
production. Especially during server restarts / client reloads,
something would result in 200 responses with no data being seen by the
frontend, despite the Django server not having received/processed the
request. Fortunately, this strange failure mode appears to have
stopped happening in late 2019, so we can delete this hack.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 9aa5082d63 (#20673) incorrectly
changed the name of the error callback passed to channel.get. This
prevented reporting of errors while moving a topic. Fix it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
When we detect that multiple messages are selected, copying will copy the
entirety of each message that is selected. [more conversation on that
here](https://chat.zulip.org/#narrow/stream/6-frontend/topic/triple.20click.20.2B.20copy.20paste.20bug/near/1398292).
This commit fixes a bug where we would select the entirety of a message
following a selection even when none of that last message's text was
selected (only some HTML element in the messages's container).
Fixes#18706.
A message selection that goes off the end of the last message in a topic
could still be a selection of only one message. We shouldn't assume that
it's multiple messages, and so there shouldn't be an assignment of
`skip_same_td_check = true`.
The table_name property was only ever undefined for the
special all_messages_list object.
In 6f764ce4b3, we downgraded that object
to only have a MessageListData; as a result, we now never construct a
MessageList or MessageListView without `table_name` set correctly.
`current` should ideally be `undefined` here to reflect the
correct narrow state but to make sure background updates of
message_list go smoothly, we set it to home.
This commit reuses set_delete_own_message_policy_dropdown to enable
or disable the time limit settings based on change in
delete_own_message_policy dropdown.
This is a prep commit for deduplicating code and using this same
function set_delete_own_message_policy_dropdown for disabling or
enabling the limit setting while changing policy dropdown.
For multi word stream names, searching for particular phrases, like
the entirety of any word in it, caused no space to show before and/or
after that word. For example, searching for `core` resulted in
`**core**team` (the space between `core` and `team` missing).
The cause of this bug was that the immediate container was `div` with
`display: flex` and so spaces at the ends of its immediate child
elements: text nodes and `strong` elements - were not respected. This
is fixed now by wrapping all the `description_html` text in a `span`
element (while the optional user_pill_context stays in another `span`
as before).
We forgot to change the selector here when we switched from a fa globe
icon to a .zulip-icon, which resulted in the new globe icon only having
the default color.
This commit makes the appropriate change.
Updates `stream_events.js` to use the subscription update event that
is now being sent for the `is_muted` stream property, instead of the
event sent for the `in_home_view` property.
Because the server is still sending events for `in_home_view`, keeps
it as a property processed by `update_property` function, but does
nothing with the event. Adds temporary test for coverage.
When the user chose to send the composebox message on pressing ctrl +
enter instead of just enter, it only worked in writing mode but not in
the preview mode.
This change makes ctrl + enter send the message even in preview mode,
when that setting is chosen.
Fixes: #21670.
I'm not sure whether the bug this fixes was a regression resulting
from d6d3683da0, or an old bug, but
focusing the compose box is not sufficient to end preview mode; we
should be calling the function that's explicitly for that.
Because the typeahead.js list items are currently just text, a user's
full name and avatar should be displayed in `input_pill`. To use
`input_pill`, a separate Handlebars partial view was created to
provide a mandatory container (`<div class="pill-container">`) for
`input_pill` and a flex container (`<div class="search_list_item">`)
for vertically aligning the text.
The description of each suggestion (i.e `description_html`) is
rendered as raw HTML, so every special character (e.g. whitespace)
should be HTML-escaped. This enables highlighting the substring in
each search suggestion that matches the query.
Fixes: #20267
Till now, switching back to writing mode after preview mode, needed
the user to first focus on the `Write` (unpreview) button by tabbing
to it (if using keyboard) and then select it.
To make things easier, especially when using keyboard, now the `Write`
button will be automatically focused on entering preview mode, so
going back to writing mode only needs one 'Enter` keystroke.
When switching back to writing mode after preview mode, the composebox
would be out of focus and so the the cursor would semingly get lost.
Now on clearing the preview mode, the composebox is focused and so the
cursor is seen blinking at it's original position.
We ensure that if message edit is disabled, then we don't send
content in request to the server.
Refactored by tabbott to match the existing pattern for how we do this
for topic/stream edits.
The "Subscribe to more streams" widget has always had this tension
between "Subscribe" vs. "Create" in a way that felt like whatever we
wrote could be confusing. To address this, we enhance the component to
advertise whether additional existing streams that the user can
subscribe to actually exist or not.
- When the user has N>0 streams they can subscribe to, we display
"Browse N more streams".
- When the user has no streams they can subscribe to (i.e. they're
already susbcribed to all the ones they could join) but the user has
permission to create streams, we show a "Create a stream" link.
- If the user doesn't have permission to subscribe to or create any
streams, we don't show a link at all.
Fixes#21865.
Co-authored-by: Jai soni <jai_s@me.iitr.ac.in>
This function was introduced in
447dc0029a74c8ff47d13fa40ce97dc10f20b522; but we haven't been using
this highlighting feature; and the last control-group was removed from
the signl page in dc2bdb2aad.
We set the custom input box empty for "Anytime" case for
message edit and delete limit settings. We also keep the
"Save changes" button disabled when changing from "Anytime"
to "Custom" since the input box is still empty.
Since, we removed the "never" option for edit-limit setting in
previous commits, we can now use same list for both edit-limit
and delete-limit setting values.
This commit adds a checkbox for allow_message_editing setting and
thus we also remove the "Never" option from the time limit dropdown
as unchecking the newly added checkbox will mean the same.
We also disable the time limit input if message editing is not
allowed.
This commit also changes the label for time limit dropdown.
Fixes part of #21739.
This commit changes the code to consider zero as an invalid value for
message_content_edit_time_limit_seconds. Now to represent the setting that
user can edit the message anytime, the setting value will be "None" in
database and "unlimited" will be passed to API from clients.
When the user added space/s right after the topic typehead symbol `>`,
a thin blue line would be selected at the top of the typeahead menu.
To avoid this and to make stream and topic typeaheads' behaviour more
consistent with each other, space/s right after `>` is not allowed,
like it is not allowed right after `#`.
Fixes: #19124.
This commit is a preparatory commit for #20870, it introduces
`handle_narrow_deactivated` and `handle_narrow_activated`
functions in pm_list.js, separately from top_left_corner.js,
to reduce the complexity of handling private messages section
separately.
Adds an API endpoint for accessing read receipts for other users, as
well as a modal UI for displaying that information.
Enables the previously merged privacy settings UI for managing whether
a user makes read receipts data available to other users.
Documentation is pending, and we'll likely want to link to the
documentation with help_settings_link once it is complete.
Fixes#3618.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Previously, our modal system prevented opening a modal when one was
already open. It appears this was implemented to work around the fact
that we're using Micromodal selectors to determine if a modal is open
(and those don't update until after an animation frame).
We'd like to support opening the full user profile and manage user
modals while read receipts is open. While we could work around this in
that place, it feels like one needs a lot of documentation in order to
add a setTimeout in those code paths.
So we instead make open_modal support this, with a guard to prevent
infinite recursion in case of future bugs.
Note that dialog_widget was already closing modals before opening the
next one, so this is a behavior change only for our 3 modals that do
not use dialog_widget.
(I'm not sure why the `dialog_widget` modals did not already require a
delay, but likely there's some CSS difference).
We likely will want to redo this to instead use a better state
tracking system.
See https://chat.zulip.org/#narrow/stream/49-development-help/topic/close.20and.20open.20another.20modal.20immediately
for discussion.
The previous version with e.target would give the element that was
clicked lying inside an element with '.view_user_profile'.
One would usually expect "data-user-id" to be attached to the
same element with ".view_user_profile" instead of any of its children.
So, to just look for "data-user-id" in the element with that class,
instead of any of its chidren, this commit changes e.target to
e.currentTarget.
We show tooltip for user read receipts setting mentioning
that the organization has disabled read receipts setting
when an organization does so. We hide the tooltip when
organization read receipts setting is enabled.
We also fix the alignment of "i" icons with label and headings
at various places by moving it 1 pixel below. There may be
some places where it is not fixed, but those will be fixed
separately.
This reverts commit 46b289cbda.
This commit didn’t pass Node tests independently of the PR #21726 that
it was split from, because pm_list is mocked.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is a preparatory commit which introduces
`handle_narrow_deactivated` and `handle_narrow_activated`
functions in pm_list.js, separately from top_left_corner.js,
to reduce the complexity of handling private messages section
separately.
Currently, if we navigate to some other topic/stream
while the message is being moved, the message edit UI
still remains open as we do not get its `row` in
`message_lists.current` since the message has not moved yet
to the stream/topic we navigated.
Hence the correct thing to do would be to delete
the message_id from `currently_editing_messages` if it
exists there but we cannot find the row.
Fixes#21724.
Previously, the topic_edited and stream_changed variables were
incorrectly used outside the loop over events, in a way that meant
we'd use the values of these from the last event, when we clearly
meant to use whether, for example, the current stream was changed.
In practice, it's rare for a client to process multiple message edit
events at the same time, but this will happen anytime a client is
offline for a few minutes during which several edits occur.
* Remove likely useless use of `controls` Bootstrap class.
* Remove outer control-group elements, which just added 10px bottom margin, and
were always used with .no-margin, which removed that margin :).
* Rename message-edit-timer-control-group to message-edit-timer, since
it isn't a control-group.
The stream list left sidebar currently has 3 sections:
* Pinned (+ Muted pinned streams)
* Active (+ Muted active streams)
* Inactive streams
Previously, these sections were separated by horizontal lines, which
did not provide an easy way to discern why there were sections. We add
labels to these section dividers to help with this.
Additionally, within each section, we now sort all muted streams to
the bottom, so that they general minimal clutter.
Fixes#19812.
In compose box, the "x" button tooltip text changed to
"Cancel compose and save draft" except when unsent
message length is short(<3).
Also in help(?) > keyboard shortcuts, text for `Esc`
changed to "Cancel compose and save draft".
The help center page updated with the above changes.
Fixes#21599.
Following c31ab1bcb5, the keyboard
navigation in Recent Topics has been buggy, because the number of
columns with actionable elements now varies with whether the topic
has any unreads.
Fix the keyboard dead reckoning logic to understand that there's a
different number of columns depending on whether the unread count is
present.
This does not fully make the experience nice, but it's enough to tide
us over for now.
Fixes: #21654.
This is preperatory commit for #21654.
We extract the logic for arrow key navigation when focused on table to
separate functions so it is easy to add more functionality in future
and will not clutter the switch block.
Fixes a part of: #21654
In future commits, it will become possible to have a non-null
`compose_state.topic()` while in private message view, because
we'll be keeping that state for switching between the stream
and private message views. See #21853 for further context.
We don't want to warn about a resolved topic unless the topic
is actively visible in the compose box.
Now the following characters are allowed before @-mentions, stream
references (starting with #) and emojis (starting with :) - space, (,
{, [, ", ', /, <.
Earlier only the opening brace type characters and space was allowed.
This allows this component to follow existing design patterns, rather
than being its own unusual element with various quirks.
The implementation is approximately the same as before I just migrated
"Edit custom profile field" form into modal, like "Add new custom
profile field" form modal.
Fixes: #21634
This commit is a preparatory commit of "custom_profile_fields: Edit
custom profile field form into modal."
The object returned by get_profile_field_info, which contained jQuery
objects for the profile-field-row and profile-field-form elements, was
just a source of unnecessary indirection, since none of the functions
consuming it accessed the row.
This lets us remove this fairly ugly user interface widget, which was
inconsistent with the rest of the settings UI.
The implementation is approximately the same as before I just migrated
"Add new custom profile field" form into a modal, status update
notifications about these forms will be displayed inside their modal,
and made some little design changes as discussed on CZO.
Fixes part of: #21634
This is a preparatory commit for commit "Edit custom profile
field form into modal."
Above mentioned commit will use class input-group instead of
control-group so here we are already changing it to input-group.
There is no control-group class to hide/show in custom profile fields
list instead there is input-group class, kind of little typo I guess
from this 9e343f1 commit.
Spamming the `s` shortcut when hovered on an image can cause the
tooltip to be displayed at the top left corner. This is caused by
original reference of the tooltip being removed from DOM. The
re-rendering is happening so quickly that tippy is not able to hide
the tooltip in time.
Uptil now only space was used as a word separating character when
searching streams. This meant that searching for "xyz" would not turn
up a stream named "stream-xyz" as one would expect.
Since -, _ and / are likely to be used as word separators in stream
names, these 3 are added as word separators for streams. The utility
function `filter_by_word_prefix_match` is refactored by adding an
optional `word_separator_regex` argument.
Fixes: #19700.
We also show upgrade banner along with disabling the setting.
We also hide the web-public stream creation policy dropdown in
such case as we do when enable_spectator_access is False.
We now allow admins to edit configuration of outgoing webhook
and embedded bots from the edit form in "Organization" settings
section. In next commit we would deduplicate the code to use same
modal in both "Organization" and "Personal" settings sections.
This commit adds option to change bot avatar from the admin bot-edit
form. This is a prep commit for making bot edit forms in both
"Personal" and "Organization" settings sections same.
We do not use dialog_widget.submit_api_request now since we need
to pass processData and a couple of other parameters with the
request since we are sending a file also as part of data. And
also we add code to show loading spinner which was previously
handled by submit_api_request.
We now show confirmation modal when deactivating bot from
personal settings section. Since we have added deactivate
option in the bot-edit modal opened from admin settins page
and we would replace the modal opened from personal settings
with that modal, it would be good to show the modal consistently.
This commit also moves confirm_bot_deactivation function from
settings_users.js to settings_bots.js to avoid cyclic dependencies.
We move show_edit_bot_info_modal function to settings_bots.js
as this code will be used for modals opened from the personal
bot settings section as well when we would make both the modals
same and this will help us in avoiding cyclic imports.
Now that we can assume Python 3.6+, we can use the
email.headerregistry module to replace hacky manual email address
parsing.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This fix excludes the bots and invitation settings tabs from having the
organization_settings_tip.hbs template being inserted in them.
Arguably we should invert the meaning of this block so the default is
that these notices don't appear, but it's hard to be sure whether we're more
likely to add a new setting panel that is normal settings or a data table.
Fixes: #19967.
Change submit button text of both bot and user deactivation confirm
modal from "Confirm" to "Deactivate".
Calling `launch()` function from `dialog_widget.js` because
`confirm_dialog.js` set submit button text to "Confirm".
We currently show stream emails for subscribed and unsubscribed
streams in stream settings overlay and don't show them for never
subscribed streams.
There is a bug where we show the empty container without email on
live update after unsubscribing and then we completely hide the
email element after we switch the stream and come back to it
again. But then we again show emails for unsubscribed streams
after reload, to preserve the beahviour of showing the emails of
unsubscribed streams.
This commit fixes this bug by not hiding stream email on live
update after unsubscribing and also showing them after switching
between different streams and makes it consistent with showing
emails for unsubscribed streams.
Fixes#22308.
We add topic auto-complete to the left sidebar menu as sometimes user
may want to merge the topic they are moving with an existing topic.
With a tweak by tabbott to remove a now incorrect comment.
Fixes#19876.
Providing additional information like number of invites and number of
bots owned by deactivating user in the confirm_deactivate_user modal
will help the administrator if they need to do any follow-up work.
Fixes#20973.
Completed-by: Ganesh Pawar <pawarg256@gmail.com>
We mention about sponsorship in upgrade banner to non-business
organizations. The message for business organizations is same
as before.
There is no explicit hover behavior for banners for org types
other than business, as banners are not themselves links in
such cases and only parts of text inside the banner are links.
Fixes#22161.
Originally, DEFAULT_NOTIFICATION_STREAM_NAME was set to
"announce" and we also showed warning in frontend when
user was composing message to "announce" stream and if
the stream had more than 60 subscribers.
But we changed DEFAULT_NOTIFICATION_STREAM_NAME to "general"
in d46b125bf2. That commit did not remove the frontend code
for showing warning and this commit removes it since there
is no "announce" stream by default now, and we would not
want to show warning when sending to "general" since that
stream could be used for many discussions and it would not
be nice experience to show warning everytime.
We do not show different error messages for different values of post
policy values if user is not allowed to post making it consistent with
other settings like wildcard mention settings and organization settings.
This also helps us deduplicate some code as we use almost same code
for excluding the streams to which user is not allowed to post from
the dropdown in moving messages UI.
After moving to settings_checkbox in Authentication Methods UI,
mentions of "table" in the related JS variable/function names
are no longer meaningful and may be confusing. Change them to "list".
The user status appears out of place among the profile fields and thus
placing it under the avatar avoids any discontinuity between the profile
fields. This also adds the status icon beside the user status.
The <kbd> elements in `static.templates.keyboard_shortcuts.hbs`
that are arrow keys have a class of "arrow-key". This adds that
class to arrow keys that are updated via `adjust_mac_shortcuts`.
Follow-up task due to changes introduced in #22330.
Updates header "Notifications" to "Automated messages and emails".
Updates these subheaders in that section:
- "New stream notifications" to "New stream announcements"
- "New user notifications" to "New user announcements"
- "Notifications language" to "Language for automated messages
and invitation emails".
Co-authored by: Lauryn Menard <lauryn@zulip.com>
We have observed infrequent storms of accesses (tens of thousands of
requests to minute) to `/` after an event queue expires. The current
best theory is that the act of reloading the page itself triggers a
focus event, which itself triggers a reload before the prior one had
had time to do anything but send the network request.
Since the `focus` event here is merely as a backstop in case the
synchronous reloading and deferred reloading fail, we need only run it
once.
Prevent a non-immediate reload from being scheduled while an immediate
reload is already in progress. This is highly unlikely in practice,
but is a reasonable safeguard.
A `reload.initiate({immediate: true, ...})` *should* not return, as it
should trigger a `window.location.reload` and stop execution.
In the event that it continues execution and returns (for instance,
due to being in the background and reloads being suppressed for
power-saving -- see #6821), there is no need to fall through and
potentially schedule a 90-second-later retry.
We show a confirmation modal when deleting option of a select-type
field mentioning number of users who are using that option. We also
show the modal if no user has selected that option. We show the modal
only in edit-form and not while creating a new profile field. We do
not show the modal when removing a newly added option during editing
the field.
Fixes#22145.
Previously, the value for an option of the select type custom
profile field was set as "order - 1". This commit changes it
to remain same even when we reorder the options or delete an
option. When we add a new option, its value is set as 1 more
than largest value already used.
This helps is eliminating various bugs in this subsystem, where
user's choice is changed unexpectedly when reordering or deleting
options.
Discussion -
https://chat.zulip.org/#narrow/stream/378-api-design/topic/custom.20profile.20fields.20option.20deletion.
This immediately shows the menu for which messages to move when the
user can edit the stream/topic of a message, but not the content of
the message. This balances the concern that this menu might feel like
clutter when doing a content edit with the fact that most of the time
when one visits this menu without content edit permissions, one will
want to be reassured that one can choose which messages to move.
Fixes#19196.
Sahil Batra
Akarsh Jain
Ganesh Pawar
Yogesh Sirsat
Lauryn Menard
Tim Abbott
Steve Howell
Riken Shah
evykassirer
Mateusz Mandera
Aman Agrawal
Purushottam Tiwari
Anders Kaseorg
N-Shar-ma
Zixuan James Li
Raghav Luthra
Ganesh Pawar
rixant
jai2201
Khushiyant
Kartik Srivastava
Sean Heckathorne
YashRE42
Oliver Pham
Dinesh
Adam Sah
madrix01
Julia Bichler
Swapnil Gore
Ivan Toymentsev
Rishant Rokaha
sahil839
anurastogiji
Nikhil Maske
Alex Tereschenko
sayamsamal
ritikBhandari
Alex Vandiver