We rename class of notification settings except checkboxes
by prefixing them with 'setting_' for clarity.
We do not change class of checkboxes because settings_checkbox
is used by other templates also and if we only change class
of those using notification_settings_checkboxes then live
update code will break and will need to add separate condition
for differentiating between which partial template is used.
This is a prep commit for adding UI for realm-level defaults
of user settings.
This commit renames notification-sound-audio element to
user-notification-sound-audio because we will be adding similar
element for realm-level default of user settings also.
We also change the child elements to have current id as their
class for the same reason.
This is a prep commit for adding UI for realm-level default
of user settings. We refactor the code to use classes
instead of ids such that we can use the common code for the
new settings.
This commit refactors change_display_setting function to accept
url as a paramter instead of directly using '/json/settings'
such that we can use the same function for realm-level settings.
This commit refactors change_display_setting function to
accept container element as a paramter and then determine
the correct status element from it. This is the prep commit
for adding realm-level default settings UI.
We add a prefix to id of default_language_modal.hbs
such that we can use the same code for user settings
and realm-level settings.
We also add a class "default_language_modal" to the
modal div to avoid duplicate css.
This is a prep commit for adding UI for realm-level
default of user settings. We refactor the code to use
classes instead of ids such that we can use the common
code for the new settings.
We were using incorrect element as we changed the input from
select to radio buttons in 439bc2920a.
This code was originally added in 6cb03ea78e (though in a
different file) and was removed from sometime and then added
again in e7311cdf5d. But in the meantime the input was
changed to radio, which resulted in incorrect code.
We were using emojiset_spinner element in destroy_indicator, but
there is no such element and emoji-settings-status element is used
in make_indicator, so destroy_indicator should also use the same
element.
This was added originally in 6cb03ea78e (though in a different
file) and was removed for sometime and then readded in e7311cdf5d.
But between these two commits, the setting was changed to be a
radio element and thus the spinner elements were also changed.
On mobile, when the sidebar is toggled, the following three issues
are encountered:
- When none of the sidebar menus are expanded, the sidebar has no
scrollbar, which is expected. But if you scroll, the background
content scrolls, which is a bug.
- When some of the sidebar menus are expanded such that the content
overflows and is "scrollable", once you get to the end of the
sidebar content, the background content keeps scrolling in a weird
way.
- If the mobile screen is wide enough, if you scroll the sidebar
content, it scrolls as expected. But if you move the pointer to
the side of the background content that is still visible, you
can scroll the background content even though it should be fixed.
This commit fixes all of the above issues.
This commit updates both the stream-level and realm-level message
retention setting to use 'unlimited' instead of 'forever' to set
message retention setting to "retain messages forever".
Earlier copy to the link present above the composebox (which
appears when a message is sent outside the current narrow), it
used to provide the link to the home page which is fixed now.
Now, copy to the link gives the link of the narrow where message
is sent.
When one resizes the window and tries to switch to the vertical
sidebar menu, the CSS transition flickers in and out. This is
less than ideal.
This commit implements a solution to this problem. The solution is
inspired by the following helpful article:
https://ishadeed.com/article/layout-flickering/
We found a bug in our top-level nav on certain Samsung phones where
tapping on the dropdowns didn't do anything. As it turns out, trying
to figure out whether touch is enabled on a device using CSS media
queries such as `(hover: none)` is very tricky business! While it
may work on some devices, it may break spectacularly on others.
This commit presents a potential solution to this. Media queries
about widths are a lot more device-independent than hover media
queries. So, this is what we do now:
- We fire click events regardless of whether the top-level nav is in
the vertical sidebar orientation or the horizontal orientation.
Since we are no longer dependent on hover media queries for click
events, this fixes the mobile bug mentioned above because taps or
clicks will always work regardless of device.
- The mouseover/mouseout events are only fired when the header is
in the horizontal orientation and the primary input mechanism
supports hovering over elements. This allows us to support hovering
over menus on desktop. However, since mouseout/mouseover events are
irrelevant for mobile, we are fine on that front since clicks/taps
will still work.
NOTE that the above approach also takes care of weird edge cases where
you have a horizontal orientation on a device such as the iPad Pro that
is flipped in the horizontal position. Since clicks work anyway, these
edge cases are largely taken care of.
Commit 9049fb3bd4 (#19176) broke these
by changing {page_params} to {...page_params}. We could change it
back, but it’s better to be explicit about which items we use from
page_params.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit makes the compose.update_fade as an exported
function and adds the listener to update the fade manually
as deleting the pill was not calling this functions.
Fixes#18865
We want to avoid passing opaque messages around to
low-level functions that only need certain fields.
This sets us up to handle mark-as-unread messages
that aren't necessarily full messages.
We only care about ~8 fields from a Zulip message
when we're tracking unread counts. For example, we
don't care about the "content" field. This also sets
us up to pull up the "display_recipient" logic in an
upcoming commit.
This reverts commit 1965584eec.
This syntax has a bad interaction with table syntax and needs to be
rethought.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
'corporate_enabled', 'realm_push_notifications_enabled'
and 'realm_digest_emails_enabled' settings are part of
page_params and not user_settings.
This was introduced in 998d710275.
The reason for this was we were not loading extra
parameters while storing the status emoji object.
For this we also need the emoji module to be initialized
early because the right sidebar would need it to display
the status emoji.
We now use the newly added "user_settings" event in the frontend
code instead of previous "update_global_notifications" and
"update_display_settings" events which are now depreceated.
This reverts commit 5e97ec9ad9.
This change has been pretty confusing for users, and so we need to do
something more in order to make the UI acceptable to change this
default.
This commit moves the warn_if_private_stream_is_linked,
needs_subscribe_warning, and warn_if_mentioning_unsubscribed_user
to compose_validate.js from compose.js.
These warning functions are very naturally part of the compose box
validation system, though they're a bit different in being called from
the typeahead codebase.
Part of splitting compose.js into more natural modules.
Previously, once the user opens the "Set user status" UI,
the focus isn't automatically set to the input bar.
This is so because the input field isn't visible at
the time when UI is loaded because of the bootstrap
fade property which delays the event.
Added a fix to trigger the focus event on input bar
only when the modal is completely shown.
Fixes#19417.
This commit enhances our Multiselect dropdown list widget by
displaying a tippy tooltip over the dropdown button once it's
text changes to `n selected` where n is the number of items
selected by user which exceeds the limit passed.
It essentially helps the user to identify the dropdown items they
have selected by just hovering over the dropdown toggle button.
This commit adds the support to select multiple dropdown items by inheriting
dropdown list widget and overriding some of it's properties.
The parameters that can be passed along with it are-
- widget_name: The desired name of the widget.
- data: The data that needs to be populated as dropdown items.
- default_text: The default text to be rendered when none of the items is selected.
- on_update: Function to trigger once the filter button is pressed.
- on_close: Function to trigger once the dropdown is successfully closed after filtering.
- value: The default value that is initially selected by user.
- limit: The maximum number of dropdown items to display on button text.
This widget can later be implemented in recent topic view to replace the
several ellipses filter button and also within the organisation user's page
to quickly sort the users list according to their org role.
Previously, our dropdown list widget was lacking several
keyUp/keyDown keyboard focus events due to which the user
couldn't shift the focus from the dropdown item to it's
search input.
This commit essentially binds several additional keyboard events
by defining a `dropdown_focus_events` function which helps
in enhancing our keyboard focus events.
Due to the above changes, it removes the custom event binded
to dropdown list widget because of which we fallback to our
deprecated keydown event handler functions present in /third/bootstrap.
This is a prep commit for adding the support of Multiselect
dropdown list widget by prototypal inheritance.
The following change actually revamps the dropdown list widget
into a constructor function, due to which the widget is now to
be initialized with the `new` keyword (which adds a property
to __proto__ object that links to the constructor function's
prototype object).
Example-
const foo = new DropdownListWidget({....});
Due to the above change, this commit also modifies the declaration
of dropdown_list_widget across all our instances.
In this case, for TypeScript narrowing to work correctly, we need
a if statement that check that both of the type are same. The one
condition we had that checked that both have the same type doesn't
work with TypeScript narrowing yet.
We use a Symbol for unassigned_value_sentinel and explictly assign
the compute_value property instead of using Object.assign. Both of
these are needed to type annotate it easily.
