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.
Tim Abbott
Anders Kaseorg
Purushottam Tiwari
Ganesh Pawar
rixant
jai2201
Zixuan James Li
Khushiyant
Aman Agrawal
Kartik Srivastava
Lauryn Menard
evykassirer
Sean Heckathorne
Sahil Batra
Ganesh Pawar