If a user clicks on the pill container and not directly on a pill
or on an "x" inside of a pill, it should be presumed they are
trying to input new text. This effectively makes the whole non-pill
section an input bar.
This now allows all tab switcher components to be used with left
and right arrows, given that a tab is already in focus, which is
the default behavior unless overridden (like on the streams
overlay).
Do not attempt to autoscroll down to view new messages if popovers are
open. This prevents the issue where someone can be viewing a profile or
reacting to a message and not be able to due to a new message coming in.
Fixes: #7319.
This adds a slide class that specifies that the JS actions for sliding
up and down sections is the desired behavior, along with a bit of CSS
to help display correctly in the case of not being a sliding section.
Add a spinner for when a stream is being created to show that
an operation is being performed, while also disallowing users to
modify the form in the meanwhile.
Commit modified by Brock Whittaker <brock@zulipchat.com>.
Fixes: #5268.
This change prepares us to have the server send avatar_url
of None when somebody wants a gravatar avatar (as opposed
to a user-uploaded one).
Subsequent commits will change behavior on both the server
and client to have this happen. So this commit has no-op
code for now, but it will soon use the fallback-to-gravatar
logic.
The i18n.t function already escapes HTML, so we should avoid
calling jQuery's text() method, which double escapes the HTML.
The symptom reported here was that if you changed your
timezone to something like like America/Mexico_City, you'd
see `/` instead of `/`.
Most callers to the `ui_report` functions clearly call `i18n.t`
on the messages with code like this:
ui_report.success(i18n.t("No changes to save!"), status);
There are some exceptions:
blueslip.js: has really long hard coded messages
reload.js: mostly says "Reloading...", which perhaps we should
translate
settings_account.js: uses helper functions
settings_lab.js: uses local variable
settings_org.js: i18n happens in property_types
ui.js: uses generic_embed_error (unaffected by this change)
Fixes#7280
This commit is easy to revert if we want to tone down errors
to warnings for the short term, while our codepath still does
proper handling for adding users when they come in messages.
This logic used to be in extract_people_from_message(), but
we are deprecating extract_people_from_message(), whereas
the maybe_incr_recipient_count() function has logic that we
want to keep.
This change is the first step in making it so that we load
non-active users at page load time in the webapp.
Before this change, we would reactively handle deactivated
users when we saw them as senders in messages. Subsequent
changes will make it a warning if we see unknown senders
in messages.
There's no reason to include deactivated users in compose
typeahead, since we won't let the compose happen.
This also removes cross-realm bots from the typeahead, which
is mostly driven by not having a convenient function to include
them, but also it's rare that it makes sense to talk to a cross-realm
bot unless replying to it.
In addition to decreasing the excessive number of bundles we had, this
will set us up to fix rendering of code blocks when clicking the
sidebar links in the /api-new site.
This commit allows for the /api-new/ page to rendered similarly to our
/help pages. It's based on the old content for /api, but we're not
replacing the old content yet, to give a bit of time to restructure
things reasonably.
Tweaked by eeshangarg and tabbott.
The "subdomain" label is redundant, to the extent it's even
accurate -- this is really just the URL we want to display,
which may or may not involve a subdomain. Similarly "external".
The former `external_api_path_subdomain` was never a path -- it's a
host, followed by a path, which together form a scheme-relative URL.
I'm not quite convinced that value is actually the right thing in
2 of the 3 places we use it, but fixing that can start by giving an
accurate name to the thing we have.
We correct a bug on Firefox where using the ESC key to close an edit
box that was opened by the left arrow key caused the message feed to
lose focus, making it difficult to navigate the message feed by
keyboard afterwards.
We fix this bug by changing the function that handles the ESC key
during an edit to pass the correct object to the message_edit.end
function.
Fixes#7072.
Lets administrators view a list of open(unconfirmed) invitations and
resend or revoke a chosen invitation.
There are a few changes that we can expect for the future:
* It is currently possible to invite an email that you have already
invited, it might make sense to change this behavior.
* Resend currently sends an invite reminder instead of resending the
original invite, this is because 'custom_body' was not stored when
the first invite was sent.
Tweaked in various minor ways, primarily in the backend, by tabbott,
mostly for style consistency with the rest of the codebase.
Fixes: #1180.
This detects the meta key being pressed to open a page in a new
tab and therefore will prevent the page animation from fading out
the body content, in case the user wants to go back to that page
again.
We were incorrectly reporting active bots as non-active in
popovers, and we had no test coverage for cross-realm bots.
We also rename the function to is_active_user_for_popover,
since the old name, realm_user_is_active_human_or_bot, suggested
the wrong semantics for cross-realm bots.
Last but not least, we only do a blueslip warning if a user id
is not found. When lookups fail, we are pretty confident that
the user is not active, so an error is overkill. We can change
that as part of issue #7120.
Fixes#7153
It's easier to unit test logic inside of people.js than compose.js.
We allow users to compose emails to any of our cross-realm bots.
Someday we may tighten up which cross-realm bots are valid targets,
since it's not necessarily the case that those bots do anything
useful when you send them messages.
This dictionary includes bots, so the reference to
"people" in the name `realm_people_dict` was misleading.
We omit `realm` for brevity sake--it's usually the case
that folks implementing new features can safely ignore
cross-realm bots, and it's on our roadmap to move those
bots into the realm.
The function name `get_realm_human_user_ids` was a lie--it
includes active bots as well.
The only user of this function is `activity.js`, which wasn't
impacted by the misleading name, because we eventually filter
out bots in the `info_for` function.
It's possible that we actually want to include bots in the right
sidebar, since they can be difficult to discover in other parts
of the UI. Or, if we want to keep the right sidebar as all
human users, we may eventually want to make the logic to exclude
bots happen higher in the stack (but for real, this time).