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.
