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.
Safari interprets transparent as rgba(255, 255, 255, 0)
`transparent black` instead of rgba(0, 0, 0, 0).
We explicitly define transparent to help safari understand the
gradients.
This fixes the bug where our gradients look black on safari
on narrow screens.
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.
At some point we must have made a change that caused the "create
stream" and "#stream name" headings to take up more vertical space,
resulting in the dividing line for the headings of the right side of
the subscription overlay to be miss-aligned with the same for the left
side. For the "create stream" panel, it also caused the scroll bar and
some content to be visible through the partially transparent bottom
section in night mode.
In this commit we reduce the padding for those headings so that things
don't look broken anymore.
OneLogin has removed the old app. The new app is nearly identical, just
with some additional configurable settings, that we don't want to touch
anyway as the default are fine - and changing the default Parameters
that are set up, so we also update the screenshot to match how it looks
with the new app.
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.
This is a prep commit for adding extended descriptions to
message_view_header, it ensures hover effects work even if we add
additional elements to the message_view_header.
`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.
* Fix time input buttons not positioned correctly.
On <768px screens:
* Center align flatpickr.
* Remove bottom arrow.
We should ideally have a semi-transparent black background
for flatpickr on mobile but it is hard to do so with flatpickr
being inserted into DOM by an external library.
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.
```
This commit adds 5px of padding between columns of
subscriber-list such that the list doesn't look too
bad on narrow widths. This does not completely fixes
the issue on narrow widths but is atleast a small
improvement.
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
In small screens, the quote used as a standin for image used
to overflow from screen as it didn't had responsive size set.
This image has additional bound of `max-width: 100%` which
stops them from overflowing which the quote did not.
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.
While we figure out a plan in #19842 to display
subscriber count for spectators without doing a heavy query
to the database, we hide this section in navbar.
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.
Previously the edit user modal element was appended inside the
settings overlay itself, so the styles for .custom_user_field
elements nested inside #settings_page were sufficient both for
edit user UI and profile section in personal settings.
e6e60107 changed the code to append edit user modal to body
element and thus existing css was no longer applied to custom
profile fields with custom_user_field class in edit user modal.
This commit fixes to have same styles for .custom_user_field
elements in #edit_user_form.
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 made it impossible to e.g. use Font Awesome icons inside a `<ul>`
list item (they worked correctly inside `<ol>` list items).
This line was apparently added in
17ad591eb4. The original thinking
behind this line is not clear in the original PR, but is likely a
forgotten relic from experiments with a custom unordered list bullet
styling.
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.
A bug in the compose.css code resulted in showing the close button in
the banner in a wrong way. The previous logic to center the button
vertically didn't actually achieve our goals, since in cases where the
text line-wraps to two lines, it'd look oddly out of place.
Fixes#19770.
* 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.
For background, the .topic_move_breadcrumb_messages and
.message_edit_breadcrumb_message classes is applied to these checkboxes.
We add margin-top of 10px to the second checkbox to space them
appropriately. Additionally, we can remove some unnecessary complexity
from the template/CSS.
With a tweak from tabbott to remove the break-row logic as well.
Fixes#19947.
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.
Clicking the entire userlist_header opens the user filter, however,
previously only hovering over the user_filter_icon would cause a
highlight effect. This commit changes the behaviour so that hovering
over the userlist_header would also cause the same highlight effect on
user_filter_icon.
This commit changes the color, opacity and hover effect of the
search_button ( the x icon) to be consistent with other elements in
the search box, the message_view_header and the gear icon to thr
right.
This commit ensures that the search_icon within the search box has the
same color, opacity and hover effect as on the search_icon in the
message_view_header when search is closed.
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).
In commit 5d91a34119 we change the
behaviour of a hover effect on search_icon to use opacity rather than
a change in color. This change made the search_icon hover consistent
with the gear icon to the right of it, it had the additional benefit
of reducing the need to define a hover effect in night_mode.css.
However, some rules targeting search_icon were leftover that still
used color, this commit changes one in zulip.scss to use opacity and
removes one from night_mode.css that is no longer necessary.
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.
This commit changes the name attribute of emojiset_choice element from
emojiset_group to emojiset such that we can use the name attribute to
get the name of setting from element.
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.
This commit adds an option to show only indicator and not save/discard
buttons using the settings_save_discard_widget. This is a prep commit
for using save/discard buttons in the realm-level defaults section
while keeping the original behavior of showing only indicator in the
user-level settings.
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.
For users who are not logged in and for those who don't have
'prefers_web_public_view' set in session, we redirect them
to the default login page where they can choose to login
as spectator or authenticated user.
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.
* Switch from underline to a smaller range of font sizes to indicate
h5/h6 headings.
* Provide margin-top for headings while avoiding problematic behavior
for messages that start with a heading.
When expanding the compose box to full screen size, the buttons below
the compose box would unexpectedly jump because of how the 100% height
interacted with padding in the default box-sizing model.
Switching to border-box fixes this.
Fixes part of #19353.
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.
This commit removes inline-block class from the subsection-parent
elements in notification settings because we do not need different
subsections to be inline. This was working correctly till now
because the widths of the subsections were large enough to not
be able to fit in same line.
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.
In some non-English languages, including Russian, the translation of
EDITED does not properly fit. The best solution is probably something
bigger or having translators abbreviate this string, but it's worth at
least this minimal change to fix extremely ugly overlap behavior for
this widget.
Actual CSS written by Greg Price.
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 change was inspired by the problem of translators needing to
translate "Subscribe" to languages that use different forms depending
on the identity of the noun being subscribed. In most places in the
app, a button with that as the entire label should be translated in
the "subscribe myself" form; but in this one it should be "subscribe
someone else".
Thinking about this, the current label is a bit misleading in English
for someone who ignores the error message text and just reads the
button, so the best fix is to just change the string, which of course
also makes things unambiguous for translators as well.
Fixes#19641. There was no whitespace between the 'checked' and 'disabled'
attribute, leading to muted checked checkboxes being neither checked nor
disabled (since `checkeddisabled='disabled'` didn't do anything).
This bug was introduced in 747e797.
This change adds a new line before the disabled template code, so that both
the checked and disabled attributes are added properly.
Tested manually to ensure the following cases didn't change when reopening
the stream settings view:
* unchecked disabled checkboxes
* checked enabled checkboxes
* checked disabled checkboxes
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.