update_ui_and_send_reaction_ajax is called from hotkeys, popovers,
reaction clicks, etc. but it is the common point to deny
spectator from creating a reaction local echo.
The availability of this option is now controlled by fancier logic in
stream_settings_ui.js, but we neglected to remove this
development_environment guard when doing so, resulting in stream
creation being broken in production environments (because the
JavaScript code depended on this value being available).
We select the first enabled radio button by default instead
of selecting "Public" because there can be case when a user
is allowed to create a private-stream only and the other
options are disabled in that case after some recent changes.
This commit adds code for live-updaing the stream-privacy choices
in stream creation form and privacy change modal on changing
"create_public_stream_policy", "create_private_stream_policy"
and "create_web_public_stream_policy".
This commit renames disable_private_stream_privacy_option to
update_private_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames disable_public_stream_privacy_option to
update_public_stream_privacy_option_state and also refactors
the code such that it can also be used to enable the option along
with disabling the option in further commit.
This commit renames hide_or_disable_web_public_stream_privacy_option to
update_web_public_stream_privacy_option_state and also refactors the code
such that it can also be used to enable or show the option along with disabling
and hiding the option in further commit.
This commit splits the hide_or_disable_stream_privacy_options_if_required
function into three separate functions for public, private and web-public
streams. This is a prep commit for live-updating the stream-privacy choices
on changing the realm setting.
This commit adds "Manage this user" option in the user-info popover
which simply opens the administrative user-info modal.
We show a spinner on submit button in this case as modal
is not closed immediately and thus we need some indicator
to show that the task is in progress. There is no spinner
on submit button in the modal opened from "Users" section
of organization settings.
Error handling for this case is different than when the
modal is opened from "Users" section of organization
settings because there is no overlay in the background
of modal in this case.
In this case, we show error inside the modal and do not
close it and in case the change is completed successfully
we just close the modal without showing any message.
Fixes part of #18944.
We received a complaint about the generation of multiple duplicate
drafts for a single message. It was discovered that the likely cause
of this was how we were handling clients that were frequently
suspending/unsuspending, we would initiate a reload when we discovered
this, and expect the `beforeunload` handler to save the draft. This
behaved correctly, however, we would also save the compose state and
fill it in via `preserve_state` in reload.js. The important detail
here is that `preserve_state` would not encode and preserve the
`draft_id` for the current message, partly because it had no way of
knowing the `draft_id` of the draft... since we have not saved it yet,
the `beforeunload` event happens after `preserve_state`. As such,
performing any action that would trigger a draft to be saved, eg
pressing Esc to close the compose box, would save a duplicate draft of
the same message.
To resolve the above bug, we (1) ensure that we call
`drafts.update_draft()` in `preserve_state`, this returns a draft_id
to us, which we (2) ensure that we encode as part of the url and (3)
set on the `#composebox-textarea` as a `draft-id` data attribute,
which we check the next time we try to save the draft, post reload.
Note that this causes us to save the draft twice, once from
preserve_state and then again from the `beforeunload` handler, but we
do not add two drafts since the second update_draft call just edits
the timestamp because it finds the `draft-id` data attribute on the
`#composebox-textarea` set by the first call.
Previously, opening a draft and closing it without changing the
content would cause us to show the "saved as draft" tooltip. This was
annoying and would cause annoying UX after fixing a bug related to
saving drafts when reloading, as such, this commit removes the above
behaviour by introducing a simple check on whether the draft contents
are edited.
In message header search bar, users didn't use to get any typeahead
suggestions if a normal filter follows search filter.
E.g.: query => foo bar stream:D
In the above case, users didn't use to get any typeahead suggestions.
This was because we had set that the callers of 'parse' function can
assume that the 'search' operator is present in the last in the query.
Because of which `get_search_result` function (in search_suggestion.js)
didn't use to show any typeahead suggestions as it used to assume that
the latest typed query is for search filters.
Fixes part of #19435.
We directly pass operators to remove dependency on narrow_state
module. This avoids a circular dependency of `filter` module
which is evident on the `/devtools/integrations/` page.
This commit extends dialog_widget class by adding a new
optional paramter validate_input which will be a function
to validate the inputs in the dialog and will be called
before showing the spinner and calling the on_click function.
Currently, the password change modal uses this paramter to
validate that the old and new password inputs must not be
empty. Since the spinner will not be initiated in the case
where form is invalid, we need not hide the spinner after
showing the error and thus we can simplify the code to use
ui_report.error to show the error messages of empty fields.
This fixes unexpected cursor repositioning behavior when the cursor was
positioned before or inside the "Quoting..." element.
The comments document the new logic, but roughly we aim to just
preserve the logical position of your cursor after replacing the
placeholder.
We also factor out a shared variable for the "Quoting..." string which
will allow us to tag it for translation in a future commit.
If you used "Quote and reply" to start composing a message, and
started typing before receiving the original message body from the
server, we ended up resetting your cursor to the start of the line
after the quote for two reasons:
* We were incorrectly fetching the pre_cursor for our replacement
operation before doing the server fetch, which meant we ignored any
editing done while waiting for the server to respond.
* Worse, we actually fetched the original cursor position before
inserting the "[Quoting...]" placeholder text. So we were guaranteed
to have at least some amount of error in the cursor position.
Fixes#20379.
Continuing the efforts to reduce dom trashing from the previous
commits, here we remove the third forced reflow by reordering the call
to $(".top-messages-logo").show() via narrow.reset_ui_state(), such
that it happens before the other DOM writes in
recent_topics_ui.hide().
Tweaked by tabbott to avoid adding an unnecessary if/else statement
around recent_topics_ui.hide.
This is a prep commit towards pushing the reset_ui_state calls upwards
into recent_topics_ui, in order to prevent a forced reflow. One side
effect of this change is that we add a call to
`narrow_banner.hide_empty_narrow_message()` from `narrow.activate()`.
This likely has no visible effect, in that the message list rendering
process would end up setting the narrow_banner state correctly, but
logically it could in the future avoid a banner from a stale banner
incorrectly appearing before we've rendered the current view.
This is a prep commit towards extracting a reset_ui_state function
which we can call from here, narrow.activate(), recent_topics.show()
and recent_topics.hide().
We want that function because it will enables us to prevent a forced
reflow when navigating from recent_topics to stream: xyz.
Going through the description of commit
a150b9b0ae is highly recommended since
this is a related issue.
We had received a complaint on chat.zulip.org about navigation with
the keyboard `n` key being significantly slow (~5 seconds), the first
time `n` was pressed when starting from the recent topics view.
It was difficult to reproduce the amount of lag that was reported, but
running chrome with the profile tab set to 4x slowdown helped get
close to it.
Based on profiling from the original report, as well as locally with
chrome set to 4x slowdown, led to the realisation that recent topics
to stream navigation involved a lot of dom thrashing, and so this
series of commits aims to prevent this path from causing forced
reflows.
In this commit, we reorder the calls to $(...).show() in
recent_topics_ui.hide(), this prevents the first reflow in this path,
most likely because displaying message_feed_container before
message_view_header_underpadding was guaranteed to cause style
recalculations since the underpadding is visually above the message
container.
This causes a net 60 ms decrease in the first renarrow, an ~ 70 ms
increase in the second renarrow and an ~ 5 ms increase in the third
renarrow but, more importantly, it eliminates one reflow and sets on a
path where we can achieve strong gains in subsequent commits.
We show "Please enter your password" error inside the modal
if the "Old password" input is empty and "Please choose a new
password" error if the "New password" input is empty and do
not send a request to server.
Fixes#19901.
The stream creation form currently does not setup its own handler for
displaying the "N:" input when ".stream_message_retention_setting" is
changed.
Prior to e793ef7f62d280300afeeab2f4a086e99858a5a9, this form would
sometimes work as intended because stream_edit would set the handler
on this dropdown, when it was opened. However, after that commit, this
would simply never work.
Hence, in this commit, we make changes so that stream_create correctly
sets the handler on its dropdown. This causes us to repeat ourselves a
little and as such is not the cleanest solution, but this might be the
best we can do due to the complications of stream_edit opening a
modal.
The stream creation form also uses the same stream_types template as
the stream privacy modal, however, it currently does not setup its own
handler for displaying the "N:" input when
".stream_message_retention_setting" is changed.
Previously, if one opened the stream creation form, then opened the
stream edit modal, and then went back to the stream creation form, the
drop down would correctly also .show() the input, because the handler
here would also target that selector. This is incorrect since we can't
always expect the stream_edit modal to be opened first, stream_create
should set up its own handlers.
Hence, as a prep commit to fixing stream_creation, and to ensure we
don't add duplicate handlers, in this commit we change all selectors
that targeted ".stream_message_retention_setting" to
"#stream_privacy_modal .stream_message_retention_setting" in this
file.
The public and private stream choices in stream creation form are disabled
according to create_public_stream_policy and create_private_stream_policy
settings. It is not needed to disable them in stream privacy modal since
only admins can change the privacy of stream and they are allowed to
create public and private streams always irrespective of the setting.
This commit has the following changes -
- Adds dropdown for changing create_web_public_stream_policy and this
dropdown is visible only if settings.WEB_PUBLIC_STREAMS_ENABLED and
enable_spectator_access is set to True. This dropdown is live-udpated
on changing enable_spectator_access setting.
- The web-public stream option in stream creation form and stream privacy
modal is hidden if one of settings.WEB_PUBLIC_STREAMS_ENABLED or
enable_spectator_access is set to False except in stream privacy modal
when the stream is already web-public so that the user is not confused by
none of the options being selected.
- We disable the web-public stream option in stream creation form and
in stream-privacy modals of stream which are not already web-public
when the user is not allowed to create web-public streams as per
create_web_public_stream_policy setting.
- We use on_show parameter to hide or disable the options in stream-privacy
modal because we use the visible property of element to remove the bottom
border from last element in the stream-privacy choices and thus we have
to wait for the modal to be visible.
Fixes#20287. Fixes#20296.
This commit adds user_can_create_web_public_streams function
in settings_data.js which will be used in further commits
to disable or hide the UI elements for creating web-public
streams.
We do not have 'realm_' prefix to the settings used as keys
in realm_settings object, we directly use the setting name.
This commit removes the 'realm_' prefix from enable_spectator_access
setting.
This is a very frequently requested feature for organizations that are
new to Markdown, that brings Zulip's UI more in line with that of
competing projects and other markdown editors like the GitHub UI.
This works surprisingly unlike my previous attempts to do so.
WARN: This is a pseudo commit and should only be merged with upcoming
compose box bottom refactoring commit since the css changes required
for this change are missing here and are not required after that
commit.
Since we have the drafts button in top left corner and we need space
to insert formatting buttons in the bottom of compose box; removing
drafts link makes sense.
This provides a convenient interface to hide all drafts.
Fixes#19360.
However, we may want to continue to implement a button in the drafts
overlay as well for doing this operation.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
In commit 3d86267041 we add logic to
`/shared/emoji.js` which duplicated some of the logic in this
function. Since this isn't desirable, we remove the duplicate logic
here and instead just call `emoji.get_emoji_details_for_rendering`.
Previously, if a user had a realm emoji set as their status emoji and
someone deleted the realm emoji, the app would fail to initialize,
because of the error we throw from `./shared/js/emoji.js`.
This commit fixes this by just displaying the deactivated emoji,
similar to how we do when realm_emoji used as reactions are deleted.
As part of the fix, we add a function get_emoji_details_for_rendering,
which duplicates some of the logic used in `reactions.js`, we can
refactor to remove the duplication in `reactions.js` in future
commits.
Note that the following behaviour is a part of our design:
If a user sets their emoji to a particular realm emoji, say for
example "octo-ninja", and "octo-ninja" was then deleted, and a new
emoji was added with the name "octo-ninja", the user's status emoji
would change to show the new emoji instead of the deleted emoji.
Also note that in the `user_status.js` node test, we were able to
change the name for the 991 realm_emoji because it had not been
previously used anywhere in the test (possibly added as just a copy
paste artifact?).
Fixes: #20274.
emoji: Use reaction_type parameter to analyze emoji.
This commit renames "Automatic" option in color scheme setting
dropdown to "Sync with compute". We do not change any variables
used in code just the text in the dropdown visible to user.
Fixes part of #20228.
We restrict access of messages from web public streams if
anonymous login is disabled via `enable_spectator_access`.
Display of `Anonymous login` button is now controlled by
the value of `enable_spectator_access`.
Admins can toggle `enable_spectator_access` via org settings in UI.
Changes `update_page` to only update the modified user setting instead
of updating all of the user settings on the page. This is modeled on
the behavior for updates to the realm user default settings.
This is a follow up on feedback in #20070.
Now that it's further away from the composebox, we probably want it to
be visible for longer. Doubling it from 1.5 seconds to 3 seconds seems
reasonable to start with, although we should tune it based on feedback.
Now that this is in the left sidebar, we can remove the now-redundant
compose area button for it. This also changes where the "Saved as
draft" tooltip appears.
This currently shows the drafts as a popup. Eventually, we'll want to
migrate it to be a view in the center pane, as we did with Recent
Topics.
This uses the same style as starred messages in order to show the number
of drafts.
See CZO for more context:
https://chat.zulip.org/#narrow/stream/101-design/topic/drafts.20in.20sidebar
Since the position of topic in recent topics can change, we
focus the last selected topic using the `topic_key` instead
of relying `row_focus` value which is incorrect.
When user is scrolling, we simply keep the center element in
focus.
When user is using hotkeys, we keep the focused element in
center.
When user is using keyboard, we need to always keep the
"focused" topic in visible scrolling area.
We determine if the topic row is above or below the visible
area and scroll half_height_of_visible_area so that the selected
topic is visible.
This gives a nice navigation experience for both the views.
Reduced height of recent topics table to account for
compose box so that focused element is not below compose box.
Previously, opening multiple message_edits and then drag-dropping a
file into any one of them would cause all of them to upload ie you'd
get one uploaded file in each message_edit.
This bug was caused by returning multiple elements from
upload.get_item("drag_drop_container", config) when config.mode =
"edit".
This commit changes the selector to use the row provided (config.row),
and so ensures that the above bug doesn't happen.
Aman Agrawal
Tim Abbott
Sahil Batra
Anders Kaseorg
YashRE42
Ganesh Pawar
akshatdalton
juliaBichler01
Julia Bichler
Johan Ehinger
Manan Rathi
Lauryn Menard
Wesley Aptekar-Cassels