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.