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.
The text inside save/discard widget buttons was misaligned with
respect to the icon in the button. To align it properly, we add
vertical-align and a reduced line-height property to the span.
Fixes: #20583.
Resolves the issue by aligning the buttons with the text.
It's not entirely clear why text-bottom is the correct alignment, but
visually it seems to be correct.
Fixes: #20583.
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.
* Remove Bootstrap `form-horizontal` class and !important override
required by it.
* Standardize on 10px bottom margins; this fixes subtle bugs in some
sizes.
Previously, we had you select where to send notifications before
specifying which messages you're moving, which seems like the wrong
decision hierarchy.
Fixes#19973.
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.
Since we updated the bot edit form opened from "Personal"settings
section to be same as that opened from organization settings
section, we do not require this file anymore.
Fixes: #22033.
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.
The "for" attribute of label of full-name input in
admin_human_form.hbs was set to "full_name" which is already the
ID of full name input in profile section and not the input in
this form.
As a result, the modal was being closed on clicking on that
label. This commit for now just updates the "for" attribute
for full-name input to the correct ID.
The "for" attribute of label of full-name input in
edit_bot_form.hbs was set to "full_name" which is already the
ID of full name input in profile section and not the input in
this form.
As a result, the modal was being closed on clicking on that
label. This commit for now just updates the "for" attribute
for full-name input to the correct ID.
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.
Fixes some in-app and documentation references to to new user
announcements and new stream announcements that were still using
'notifications' to refer them. These were missed in the original
pass for updating this language.
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.
A bot is technically a special case of a user, in terms of how they're
stored in the database at least, but for end users, we avoid referring
to them that way.
Fixes part of: #22482
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".
On registration and login pages on self-hosted Zulip servers,
it is not helpful and confusing to show the full navigation footer
for the Zulip website. Instead, we should show a minimal footer.
Fixes#21776
When some value is very long as in the case of a long email address,
the text used to flow and hide under the profile avatar. We want the
values to be seen at all times, even if they need to be broken into
multiple lines.
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 placement of the avatar on the right makes the full profile modal
UI consistent with Settings > Profile UI. This also helps the custom
profile fields appear more in line with the default profile fields.
Fixes#21805
This makes the Full Profile layout consistent with the Manage User
layout. Also, since both email id and user id are used to identify a
user, they should be placed together.
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.
Tim Abbott
Dinesh
Sahil Batra
Anders Kaseorg
jai2201
evykassirer
Rishabh-792
Biki-das
Adam Sah
Ganesh Pawar
anurastogiji
madrix01
Julia Bichler
Yogesh
N-Shar-ma
Aman Agrawal
Swapnil Gore
Ivan Toymentsev
Rishant Rokaha
Lauryn Menard
sahil839
Nikhil Maske
om2137
Alex Tereschenko
sayamsamal
Lauryn Menard
ritikBhandari
Alex Vandiver