The logic for hash redirects for stream settings did not check
for deleted or non-existent streams. Thus a hash of the form
`/#streams/{invalid_stream_id}/*` gave gave a blueslip error.
This change fixes that logic to treat such hashes equivalent to
streams whose settings cannot be accessed by that user and
redirects such invalid hashes to `/#streams/subscribed/`.
Since emojis can have multiple aliases, an emoji was often suggested
under multiple names (like `smiling devil` / `smiling imp`), crowding
typeahead suggestions redundantly, and taking up the place of other
potentially relevant emoji suggestions.
Now such duplicates are removed post the sorting of suggested emojis,
and only the most relevantly named (highest sorted) copy is retained.
Uptil now, the compose box's state was retained across narrows only if
the compose box had any content in it. Else it was reset to match the
current narrow.
To not lose any changes made to the recipient fields only, the compose
box will now retain its state also if the recipient (stream, topic or
PMs) has been manually edited.
This is achieved by having a variable in `compose_state` track if the
recipient fields were changed, and checking it before resetting the
compose box on narrowing. This variable is reset when the compose box's
context is changed by clicking on a message, or when a message is sent.
Fixes: #23064.
This commit adds code to disable save button when the value
in custom input box is too large for an integer. Note that
since the value for message edit, message delete and email
notification batching settings are in minutes in the custom
input but are sent to API in seconds, we make sure that the
seconds value should be inside the range.
This commit adds code to convert $custom_input.val() to Number
in get_message_retention_setting_value such that values like
"48aa" are treated as NaN and we correctly show save-discard
widget with save button disabled. If we not convert it to Number,
Number.parseInt will just convert "48aa" to 48.
This commit is similar to 711536f53a.
This commit disables the "Save changes" button when there is
an invalid value in custom input of message retention setting.
This commit includes changes for both realm and stream message
retention setting.
This commit renames admin-realm-time-limit-input class to
time-limit-custom-input such that there is no confusion
when it is used for stream settings also.
This commit refactors code for realm waiting period setting
to be similar to other time-based inputs. We also add the
code to disable the save button when custom inputs have
invalid values.
This commit renames custom_days option for realm waiting
threshold setting dropdown to custom_period such that we
can reuse existing code for similar time-limit settings.
Moved the "Retention period (days):" under the dropdown "Custom".
This is consistent with similar date window inputs elsewhere, and
conveniently just requires changing a single class.
Fixes: #23532
Replaced the "Retain for N days after posting" option with "Custom".
Only show the spot for entering the time if that option is selected.
Labeled the custom time like we do for message editing:
"Retention period (days): [ ]".
This is now consistent with similar settings.
Fixes part of #23532.
This commit removes form-horizontal class from various modal
templates. We add CSS for margin-bottom property for select
and input elements to keep the design same as before. Most
of the added CSS can be removed once we remove bootstrap
CSS completely for these elements.
We can safely remove this class since vertical-align property
is already present due to other bootstrap CSS. And
margin-bottom property for checkbox inputs are added by
bootstrap and for text inputs inside ".new-style" element it
is handled in app_components.css. For other inputs, this commit
adds CSS as mentioned above.
The display property for inputs other than checkbox and select
elements is set to inline-block by other bootstrap CSS.
For checkbox-type inputs browser sets display property to
inline-block but it is eventually computed to "block" as the
float property is set to left and so it is not required to
set display property for checkbox type inputs.
This commit removes form-horizontal class from form elements
in user profile, org profile, org settings and org permission
pages. We also add margin-bottom property for select elements
in this page.
We can safely remove this class since vertical-align property
is already present due to other bootstrap CSS.
And margin-bottom property for checkbox inputs are added by
bootstrap and for text inputs it is handled in
app_components.css.
The display property for inputs other than checkbox and select
elements is set to inline-block by other bootstrap CSS.
For checkbox-type inputs browser sets display property to
inline-block but it is eventually computed to "block" as the
float property is set to left and so it is not required to
set display property for checkbox type inputs.
We have added CSS for select elements in settings.css which can
be removed later once we remove bootstrap for select elements
completely.
This commit removes form-horizontal class from time-limit-setting
div in notfication_settings.hbs. We can safely remove this class
since display and vertical-align properties are applied for select
and input elements by other bootstrap CSS, the margin-bottom
property for custom input is applied by existing CSS in
app_components.css and this commit adds margin-bottom property for
select elements.
The CSS added in this commit will probably be removed once we
remove bootstrap CSS rules for select elements completely.
This commit removes form-horizontal class from form elements
in custom-emoji, linkifiers, playgrounds, default-streams,
default-user-settings, auth-methods and user privacy settings
templates.
We can safely remove this class because vertical-align property
for input elements is set by other bootstrap CSS and margin
property for text inputs is set in app_components.css and for
checkbox inputs it is set by bootstrap itself.
The display property for inputs other than checkbox and select
elements is set to inline-block by other bootstrap CSS.
For checkbox-type inputs browser sets display property to
inline-block but it is eventually computed to "block" as the
float property is set to left.
This commit removes form-horizontal class from form
elements in alert-words, realm-exports and user-privacy
pages.
We can safely remove this class since there is no select,
input, help-inline or input-append child elements for these
and thus this class is not used for applying any CSS rules.
This commit removes form-horizontal class from form element
of inline topic edit form. We can safely remove this class,
since all properties applied by bootstrap using this class
are already overridden by specific CSS for the input element
in zulip.css.
This commit removes form-horizontal class from invite_user
template. We can safely remove this class as vertical-align
property is already handled for input and select elements
by other bootstrap CSS.
For checkbox type inputs, the display property is already
set to inline-block by browser for all input elements but
it is eventually computed to "block" since float property
for this element is set to left. So, setting display
property is not necessary for checkbox input.
We add margin-bottom property CSS for now and that can
eventually be removed when we remove bootstrap CSS for
these elements completely.
This commit removes form-horizontal class from password reset
pages (page in which user enters the email and the page where
user sets the new password) and user register page.
We can safely remove the form-horizontal class, since the
vertical-align property is already applied by other CSS
in bootstrap and margin is overridden by CSS in
portico_signin.css.
For checkbox type inputs, the display property is already set
to inline-block by browser for all input elements but it is
eventually computed to "block" since float property for this
element is set to left. So, setting display property is not
necessary for checkbox input.
For the help-inline elements, the display and margin properties
are overridden in portico_signin.css and vertical-align property
is handled by CSS for "help-inline" class in bootstrap.css.
This commit removes form-horizontal class from form elements
in social_auth_select_email.html. There is no visible input
element in the form element so the bootstrap CSS using
"form-horizontal" class does not apply to any of the elments
in the page, so removing this class does not have any affect.
The "form-horizontal" class is used in portico-signin.css for
adding hover behavior, so we add a new class "select-email-form"
and use it to add the hover behavior.
This commit removes form-horizontal class from account_accept_terms
template. We can safely remove this class because vertical-align
property is already handled for input element by other bootstrap CSS
and margin is overridden by CSS in portico.css. The display property
is already set to inline-block by browser for all input elements
but it is eventually computed to "block" since float property for
this element is set to left.
For the "p" element used to display errors, the display and margin
properties are overridden in portico_signin.css and vertical-align
property is handled by CSS for "help-inline" class in bootstrap.css.
We can safely remove the form-horizontal class from form element in
support request page, since the display and vertical-align are already
applied by other CSS in bootstrap and margin is overridden by CSS in
portico_signin.css.
`check_version` in `install-yarn` had the rather careful check that
the yarn it installed into `/usr/bin/yarn` was the yarn which was
first in the user's `$PATH`. This caused problems when the user had a
pre-existing `/usr/local/bin/yarn`; however, those problems are
limited to the `install-yarn` script itself, since the nearly all
calls to yarn from Zulip's code already hardcode the `/srv/zulip-yarn`
location, and do not depend on what is in `$PATH`.
Remove the checks in `install-yarn` that depend on the local `$PATH`,
and stop installing our `yarn` into it. We also adjust the two
callsites which did not specify the full path to `yarn`, so use
`/srv/zulip-yarn`.
Fixes: #23993
Co-authored-by: Alex Vandiver <alexmv@zulip.com>
Documents link to the bot's user card from the bot's name in
Organization settings > Bots, and information in the bot's user card.
Fixes part of #23970.
This makes it easier to browse details on users and bots when
interacting with them in the settings interface.
While the original issue was about just the bots panel, this is
clearly useful for all users.
Fixes: #23970.
Updates the help center article to match the style and formatting
of "Import from Slack" and replaces existing content with its
corresponding Markdown macro.
We used to make message failed button (retry / cancel) invisible
when the message is successfully send instead of not rendering them.
This resulted in them being accessible via keyboard when they are not
visible. I couldn't find a reason for retry and cancel buttons to
use `visibility` to be hidden instead of just being not rendered via
`display: none`.
The focus rectangle would spin along with the arrows, which looked bad.
We do want to allow focus rectangles on this element for keyboard interaction,
so we just disable the focus rectangle during the animation.
Fixes#24110.
Since fbe9a9e539, the top_navbar element
unconditionally has the rightside_userlist class. There's some CSS
associated with this class NOT being present, which can be deleted as having
no effect, and then we can remove the class as having no effect as well,
Messages sent by muted users are hidden. To make sure they are
displayed properly, we provide them a HTML structure similar to
that of a normal message so that any CSS applied to a normal
message also applied to it.
This fixes message controls being misaligned in hidden message.
This commit adds a warning to the confirmation modal displayed when
the last user of a private stream attempts to unsubscribe. The warning
explains that, as the only subscriber, unsubscribing will result in the
stream being automatically archived. This change helps ensure that users
are aware of the consequences of their actions and can make informed
decisions.
Fixes: #23954
It is possible to send the message twice by clicking send button
very quickly twice or by pressing enter and send button simultaneously.
This can be easily reproduced for large messages sent in a stream
narrow. Hard to reproduce for small messages or in PM narrows.
I was not able to reproduce locally, but was able to reproduce on
chat.zulip.org. So, this is an untested bug fix.
Fixes#22562