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.
`calendarContainer` is defined for flatpickr instance if it is
open.
This also fixes a bug where the flatpickr doesn't open when
user tries to toggle it using the global time icon in compose.
We need to handle live-update of twenty_four_hour_time setting
separately in update_page because the database value of this
setting is boolean but we use dropdown in the frontend for this
setting with option values as "true" and "false" strings.
There was no heading for "Time format" setting in the
"Default user settings" section and thus no save-discard
widget to update the setting. This commit fixes the bug
and changes the heading to be only "Time" since there is
no realm-level default of language setting.
This bug was introduced in adb612a0b4.
Flatpickr tries to show a different picker for mobile which
is not visible for some reason. We display the same picker
on mobile which we know works for our use case.
Docs: https://flatpickr.js.org/options/
```
Set disableMobile to true to always use the non-native picker.
By default, flatpickr utilizes native datetime widgets unless
certain options (e.g. disable) are used.
```
Previously, navigating from any stream to the recent topics view would
cause a forced reflow every time we checked `is_visible()` because it
would call `$("#recent_topics_view").is(":visible")`.
The reason for this is related to how browsers ship frames, the
process follows these steps:
JavaScript > style calculations > layout > paint > composite.
(The layout step is called Reflow in firefox.)
Typically, the browser will handle these steps in the most optimal
manner possible, delaying expensive operations until they're needed.
However, it is possible to cause the browser to perform a layout
earlier than necessary. An example of this is what we previously did:
When we call `top_left_corner.narrow_to_recent_topics()`, we ask to
add a class via `.addClass()`, this schedules a Style Recalculation,
then, when we call `message_view_header.make_message_view_header()` it
calls `recent_topics_util.is_visible()` which calls
`$("#recent_topics_view").is(":visible")`.
Before the browser can get this value, it realizes that our dom was
invalidated by `.addClass()` and so it must execute the scheduled
Style Recalculation and cause a layout.
This is called a forced synchronous layout.
This commit adds a JavaScript variable representing the visible state,
in order to prevent the above behavior.
This commit reduces the main thread run time of
`build_message_view_header` from 131.81 ms to 5.20 ms.
Unfortunately we still have the case where
`recent_topics_ui.revive_current_focus()` calls
`recent_topics_ui.set_table_focus()` which causes a reflow.
However, by eliminating this reflow we still save ~100ms.
(It's important to note that we only save this sometimes, as other
things can still cost us a reflow.)
Further reading: https://developers.google.com/web/fundamentals/
performance/rendering/avoid-large-complex-layouts-and-layout-thrashing
PR #19576 added a settings option for selecting a notification batching
period. We want to extend that UI option with the ability to select
a custom period.
Tweaked by tabbott to have the natural model that picking a value
present in the dropdown live-updates to remove the custom input,
rather than only having the custom input disappear on reload.
Fixes#19713.
It's always better to use the user ID than the email for fetching data
about an object whose unique ID we have, which should be all of them.
And it's also cleaner code to use the standard people.js method; tabbott
checked that indeed all callers get their `user` objects from `people.js`.
Since we restrict spectators from having access to avatars using
email to avoid someone brute forcing a user's email, this removes
a 401 response from the server in spectator view when trying
to open user info popover.
Additionally, this fixes the cached-fetching behavior documented in
the comments we add about the way we construct URLs.
This commit updates the error message returned when the maximum
invite limit for the day. We update the error returned by API to
only mention that the limit is reached and add the suggestion
to use multi-use link or contact support in the message shown
in webapp.
Add `escape_navigates_to_default_view` as a bool setting in
UserBaseSettings model and implement it as a checkbox that toggles
the hotkey implementation of escape to the default view in the
advanced user display settings.
With /help/ documentation edits from Alya Abbott.
Fixes#20043.
A user wouldn't differentiate between a "normal" modal and a "settings"
modal. If one shows up instantly, one would expect all the others to do
the same. The difference between Bootstrap fade and non-fade is pretty
noticeable (300 ms for fading).
This is a prep commit for the Micromodal migration which will have 120ms
as the animation time which wouldn't feel slow.
We attach the DOM for the modal to the body element
to avoid style interference from other elements and having to choose
a separate parent element for every single dialog_widget.
Previously, there existed a bug where clicking an open message edit
box when the compose box was open would not focus the message edit
contents, but would instead:
- focus the message edit content,
- close the compose box,
- and unfocus the message edit content.
That first bug was fixed in 4e1525d7c4
which eliminated the unfocus part of that problem, but closing the
compose box is undesirable here anyway, since often it can be useful
to have compose open while interacting with the sidebar filter widgets
or working on editing a message.
Click_handler.js was created in commit
e5467d3268 by moving code from ui.js.
While making this change, some handlers were rearranged, but the part
of this comment saying "... code above" was never changed. This commit
changes that part of the comment to refer to the correct handler
(which is labeled by a comment as MAIN CLICK HANDLER).
The `make_compose_box_original_size` function is designed in such a
way that it should only be called when it actually needs to resize the
compose box. In 3 of the 4 places that called it, we checked whether
the compose was already the original size; this fixes the 4th to do
the same.
Since it's a button, it doesn't need the "keydown" event. So,
removed it. This fixes the bug where pressing any key while the
avatar's delete_button was in focus would pop up the modal.
It was introduced in e5d0448505.
This provides a cleaner organization for our display settings, to make
browsing them more intuitive for new users.
We still need to update the /help/ documentation following this migration.
Fixes#19960.
Removes the `/day` and `/night` options from the typeahead menu while
still allowing the commands to be used. Typing `/day` and `/night`
will now suggest `/light` and `/dark`, respectively. Also changes the
`Dark mode` and `Light mode` popups that appear after using the
corresponding command.
Fixes#18318.
* Remove unnecessary json_validator for full_name parameter.
* Update frontend to pass the right parameter.
* Update documentation and note the change.
Fixes#18409.
This fixes an issue where the auto-complete dropdown doesn't reflect
the changed stream in the message edit UI.
We add an unlisten method to the typeahead library to support this
reinitialization cleanly and in a way that can be readily reused in
the future.
Fixes#19874.
It can be pretty annoying to lose your place when replying to an old
message, even though every other chat application does this. And it
doesn't really buy us much; the user can always scroll down if they
want to, we have a helpful notification about where their message is
(which could be improved), and then we don't need to add some sort of
new complicated logic to avoid marking messages as read unexpectedly,
which the existing logic for this block badly needed.
(It had existing logic of that form dating from the pre-unread counts
pointer era).
Fixes#11462.
The from_scroll=true setting has been present since essentially the
beginning of time (6ae117ea5f), and has
moved around a number of times since. It's possible that it was
correct with the UI model as originally implemented, but the behavior
it creates now is that sending a message in the home view does not
move the cursor, and sending in a narrow does, without any intent
behind that behavior.
Further, the logic for controlling whether to display a "Scroll down"
notification clearly expects that this code path will actually trigger
a scroll to the current message, which would be the case without the
from_scroll setting.
This commit refactors the display settings code to use
a single handler similar to what we do in notification
settings. We still keep default language and emojiset
setting as they are handled differently and they do
not call 'change_display_setting' directly on changing
input.
We refactor the 'change_display_setting' to directly
accept status element as parameter and not class as
a string. We also add a common class to the subsection
div such that we can get status element for each of
them easily.
We do not need to check for_realm_settings variable for
left_side_userlist handler since realm-level defaults
now uses save-discard widget and we return early in
that case and thus for_realm_settings will always be
false at this point.
There is a bug when a newly created stream appears in the notification
settings table if user changes any setting in 'Streams' row of the
table even though user has not changed the notification setting of
the stream and thus the stream should follow the global-level values.
The stream is correctly not added to the table if user changes the
setting after reloading once after creating the stream.
The bug is due to the notification settings of the new-stream being
set to the user's global settings at time of stream creation which
are not overridden since the stream-creation event contains only
stream fields and not subscription fields. And the newly created
stream is not present in the table after reload because during
initialization of the client-level data structures the notification
setting values are overridden by the values stored in server.
This commit fixes create_sub_from_server_data code to initially have
the notification settings set as null in the sub object which are
overridden by the correct value during initialization. This keeps
the notification setting values as null just after stream creation.
Fixes#19933.
This will be useful to let users enable/disable
sharing read receipts once we add that feature.
Note: Added "I've" to IGNORED_PHRASES in
tools/lib/capitalization.py to avoid capitalization
errors for the label text of this setting.
Note: These are not functional in enabling/disabling sending of
typing notifications with this commit.
Refactored the privacy settings update to keep the code less
duplicated along with making the addition of new settings easier.
This isn't necessary as `settings_checkbox.hbs` template used
for presence enabled setting in `account_settings.hbs` takes
care of checking/unchecking this checkbox.
I believe we intended to show 'several users are typing...' only
if number of typists are more than 3 but not 2.
The variable name MAX_USERS_TO_DISPLAY_NAME and commit message of
dba21d201c which added this also
suggests the same.
We remove patch_url from settings_notifications.user_settings_panel
since realm-level defaults section uses save-discard widget and its
code is separate from user notification settings and we can directly
use "/json/settings" as url in user settings code.
We do not need patch_url field in realm_default_settings_panel
because we use save-discard widget in realm-level defaults section
which is handled separately from user display settings.
We remove patch_url from settings_display.user_settings_panel
since realm-level defaults section uses save-discard widget
and its code is separate from user display settings and we
can directly use "/json/settings" as url in user settings code.
We don't need container element and patch_url in change_display_setting
since this function is only used for user-display settings and not for
realm-level settings which now uses save-discard widget. So we do not
pass settings_panel as parameter to change_display_setting.
We added language_modal_elem to settings_display.user_settings_panel
object considering there would be realm-level default_language
setting and we would need to access the modal element using a
variable to avoid code duplication. But now we have decided that
we do not want the setting and we would instead use browser's
language to set the language for new user, so now we do not need
this variable and we can instead use id of the modal directly.
This handler was broken during refactor
78d511fd03, as we can see from the
original implementation in 30065b4ee8,
the intent is that hovering over any link within the
narrow_description should not cause the search_icon to change color ie
the hover effect should not be used. This is so because it aligns
with the fact that clicking the links would not open the search bar.
However, during the refactor this was incorrectly switched to forcing
the effect to be applied when we hover over links in the
narrow_description.
This commit reverts to the original and intended behaviour, and also
switches to using opacity rather than color, in accordance with the
changes from the previous commit
(316d499ac74c2caddb57c98a43d9b776b1b32d98).
This commit removes unnecessary if condtions which are checking
for_realm_settings value which are basically present to handle
the code which is only for user-level settings, but since we
now return early for the realm-level defaults code we do not
need these conditions.
This is done in a separate commit just to make the original commit
adding save/discard widget easy to review.
Previously, on receiving udpate event of realm-level default setting,
we updated the whole page, but this might be problematic now in case
where user has edited settings in two subsections with save/discard
button still present and if user clicks on save button of one
subsection then the setting in other subsection also resets to its
original value as whole page is updated.
So, this commit changes the behavior to only update the changed
setting and not affecting other settings similar to what we do
in 'Organization settings' and 'Organization permissions' sections.
We also do not call 'settings_display.report_emojiset_change' when
realm-level default of emojiset setting is updated because we now
uses save/discard widget.
This commit adds save-discard widget in the realm-level defaults
section. We use most of the functions used in settings_org.js
by passing for_realm_default_settings and add conditionals
according to it.
Some of the major changes wrt to the organzation settings code
are -
- We use element name attribute here to get the setting name from
element instead of id. We can add id for the elements here but
there is a problem doing so for the emojiset setting as for the
radio buttons we use four different input elements and all being
for the same setting.
- Added separate cases in discard_property_element_changes and
get_input_element_value to handle the radio buttons.
- We do not need get_complete_data_for_subsection here because
all settings are controlled by single field in DB and single
element in UI and thus we can simply get changed setting values
from populate_data_for_request.
- Added org-subsection-parent to the subsection container and
prop-element to the input and select elements so that we can
use the existing code.
- Modified get_subsection_property_elements to just return the
input element which is selected for emoji-settings subsection and
not all the input elements because we only need the selected value
of emojiset. We need other elements also when discarding the changes
but we handle it separately.
This commit moves all the click handlers used for controlling the
behavior of save/discard widgets to a separate function such that
it can be used for realm-level default section also. This function
has container and patch_url as parameters.
This commit reorders the click handlers in notification settings,
such that we can easily move the click handlers for realm-default
settings to settings_realm_user_settings_defaults.js by returning
early.
We use 'admin-realm-form' class as selector in save-discard click
handlers instead of 'organization' which includes all the organization
settings sections, but save/discard widget is used only for some
sections and all of them are inside the form with class 'admin-realm-form'.
This will also help us to avoid code duplication when changing the realm
level defaults section to use save-discard widget.
This commit adds patch_url parameter to save_organization_settings
function such that we can use the same function for realm-level
defaults section also as those settings are updated using different
endpoint.
We directly declare the save_organization_settings function instead
of first declaring a variable and then setting it in the build_page
function. This is a prep commit for using save/discard widget in
realm-level defaults section.
Previously, the "resolve/unresolve topic" checkmark option was displayed in recipient bars
was presented to users regardless of whether they had permission to resolve topics in that
stream, which was confusing.
Fixes#19880.
Move the password tracking variables from setup to channel module.
Track password_change requests in channel.
Directly use xhr object to store `password_changes` information.
Tests modified to accomodote this change by converting strings to
objects.
The previous logic, introduced in
fa928d5cd1, crashed when visiting
"manage streams" in the case that the user didn't have permission to
create any streams at all.
We remove the more complex logic.
This isn't the right long term fix, because it means users who can
only create public streams just get a vague "Insufficient permission"
error when trying to create a private stream (and vice versa), but is
sufficient to fix the critical bug of "manage streams" failing to load.
Fixes#19895.
For text that already has the formatting that the user is
trying to apply, we undo the formatting. This gives a nice
experience of applying and removing the formatting from text
on the same button press.
Users wanted a feature where they could specify
which users can create public streams and which users can
create private streams.
This splits stream creation code into two parts,
public and private stream creation.
Fixes#17009.
Having tooltip `appendTo` to parent causes it to be trimmed by
the size of parent container if the parent doesn't have enough
size to include the tooltip. To fix this, we append tooltip
to `document.body`.
This change doesn't have proper test coverage and also doesn't work as
intended, since due to the structure of the function, we'll only
complain about invalid policy values for members in unlikely situations.
This reverts commit c69a968ffe.
This commit replaces 'allow_message_deleting' boolean setting
with an integer setting 'delete_own_message_policy'. We have a
separate dropdown now for deciding which user-roles can delete
messages sent by themselves and the time-limit setting droddown
is different.
This new setting has two options - everyone and admins only. Other
options including moderators will be added further.
We also remove the "Never" option from the original time-limit
dropdown, as admins are always allowed to delete message. This
never option resembled the case of only admins being allowed to
delete but this state is now resembled by setting the dropdown
to "admins only" and we also disable the time-limit dropdown in
this case as admins are allowed to delete irrespective of limit.
Note, this setting is only for deleting messages sent by the
deleting user themselves, and only admins are allowed to delete
messages sent by others as before.
We make zero invalid value for message_content_delete_limit_seconds and
for handling the case of "Allow to delete message any time", the API-level
value of message_content_delete_limit_seconds is "anytime" and "None"
as the DB-level value. We also use these values for message retention
setting, so it helps maintain consistency.
We should also hide the 'Other emails' heading in realm-level
defaults section when digest emails organization setting is
disabled because there is no other setting in this subsection
after we removed the enable_login_emails setting in d1732fb.
This commit does not remove the 'enable_login_emails' field from
RealmUserDefault table but it is just not used and cannot be
changed from UI or API similar to 'enable_marketing_emails' setting.
We incorrectly show message to reload in the savings indicator
for realm-level default of left_side_userlist setting. It should
be shown only for user-level setting since no change will take
place for the user changing realm-level default.
Previously, after sending a message from the full-sized compose-box,
the compose-box remained in expanded state covering the entire middle
part. Instead, it should return to the original state after the
message is sent.
There's a subtle race that would cause the "Scroll down to see your
message" compose notification to appear incorrectly, because the
full-size compose box occluded the entire message feed at the time the
message was locally echoed, even though it would no longer do so after
collapsing.
We address that by shrinking the compose box immediately before doing
a local echo, in addition to the primary code path in
`clear_compose_box`. Care is taken to ensure that we avoid shrinking
the compose box when sending a message that cannot be locally echoed
and gets an error from the server.
Tested on my Ubuntu development environment, by sending empty message,
valid message and slash commands. The compose-box only shrunk on
sending valid messages.
Fixes part of #19353.
This commit removes the existing default_twenty_four_hour_time field in
Realm table which was used to set the twenty_four_hour_time setting of
new user on joining and instead we now use the twenty_four_hour_time
field of RealmUserDefault table for the same.
With some tweaks by tabbott to clarify the documentation.
We refactor the code for user notification settings and realm-level
defaults of notification settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as separate
variables.
We refactor the code for user display settings and realm-level
defaults of display settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as
separate variables.
This commit changes the code to use container id in the
selector of the status element of presence_enabled setting
such that the correct element is selected because we will
add another element with same class in the realm-level
presence_enabled setting.
This is a prep-commit which simplifies changes when we add
web public streams condition here. Since our linter forces us
use switch then, we use it beforehand to simplify changes.
We pass user_settings object to all_notifications and
get_notifications_table_row_data such that we can use these
functions for realm-level settings also.
The container element and settings object are passed as
parameters to update_notification_sound_source. This change
is done so that we can use the same function for updating
the realm-level notification sound source.
This commit changes the click handler for playing
notification sound to use a variable instead of
directly using the element id such that we can
use the same code for realm-level settings also
by just setting the variable accordingly.
This commit creates a new module user_notification_settings.js
for user-level notification settings and the settings_notification.js
will be used as a common module for both user-level and realm-level
settings.
We also add parameters to the functions in settings_notifications.js
to pass container elem and settings object for the same purpose.
Notification settings uses '.on("change", "input, select")' to
handle changes to all types of input elements. But for realm-level
settings page, both display and notification settings have the
same container unlike the user-level settings, so we use inner
form element ".notification-settings-form" such that this handler
is for changing input of notification settings and not display
settings.
We set settings_object variable to user_settings object and then
use settings_object everywhere. This change will help us in using
the same code for realm-level settings also by setting the
appropriate value for settings_object.
We refactor the change_notification_setting function to have a url
parameter instead of directly using "/json/settings" directly.
This change will help us in using the same code for realm-level
settings also.
We add code for live updating notification batching period
setting. This commit also adds 'continue' statement in the
else-if condition of update_page function such that we do
not execute the code of checkbox settings for notification
sound and email batching period settings.
We also update the other_notification_settings list in
settings_config.ts to remove email_notifications_batching_period
and instead have email_notifications_batching_period_seconds
which is the correct name of setting used in backend and in
the events sent to the clients such that the live-update is
done correctly.
This commit removes the id from email notification batching period
setting dropdown and adds class such that we can use same template
for the realm-level settings as well. We also add 'setting_'
prefix as we do for other settings and modify the JS code accordingly.
We do not have any system user groups as of
now, but this commit is just a prep commit
to prevent any change in user-facing pages
to avoid confusion till this feature is
completed.
This change was initially made in 6117c38,
but it was reverted in 1543775a due to merge
conflicts with the typescript migration of
user_groups.js.
This commit adds code for live-updating the realm-level default
settings page which contains only display settings as of now.
This commit also adds realm_user_settings_defaults object to
zpage_params so that we can write the tests.
This commit adds a new module settings_defaults.js which calls
the functions in settings_display passing appropriate container
element and settings object as parameters.
We also add one more parameter for_realm_settings to some of the
functions in settings_dislay to differentiate between the user
and realm-level settings.
This commit refactors the code in settings_display.js
by modifying the functions to receive the container
element and settings object as parameter such that
we can use the same functions for realm-level
settings by passing appropriate container element
and settings object.
This change is needed as settings_display will be
used as a common module for user settings and realm
level settings.
We also rename the default_language_name variable in
settings_display to user_default_language_name as we
would add a separate variable for realm-level setting
in future.
Wesley Aptekar-Cassels
Aman Agrawal
YashRE42
Ganesh Pawar
Tim Abbott
isakhagg
Sahil Batra
Anders Kaseorg
Vishnu KS
Andrew McAfee
Kevin Scott
Lauryn Menard
Jonny Tran
rht
Gaurav Pandey
Pradyumna Sinha
Dinesh
Johan Ehinger
AnshVM
sahil839
Priyansh Garg
Priyank Patel