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.
This creates a template for the /team/ page that is currently just
embedded inside the /about/ page. This includes the titles for core
team members with their pictures.
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.
All links by default had an underline on hover, including when
<a> tags were wrapping <div> and <img> tags, which made for a small
underline near them on hover. This better focusses the underline
behavior to just paragraphs and lists.
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
This adds two constraints to the image:
1. The `max-width` can not be more than 500px (which prevents it
from being to vertically tall.
2. The `display` is set to `none` below 1024px because the image is
too small at that point to be legible.
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).
This changes some text that would display gray when on a blue body
text page; we considered changing the opacity instead, but probably we
should just delete this..
This changes the <ul> styling so that when not nested in a <p>
tag it'll have the standard font-weight (400) and be the same
color as the body text (blue/gray).
This removes the old blue styled outline around the PM recipient
box that was part of the older bootstrap styling in favor of the
dark outline on :focus that had been implemented for the rest of
the recipient boxes recently.
This creates a dropdown in place of the normal register/login links
you get when logged out, with an option to go to the app or log out if
that appears you click on the avatar.
A bit more work is needed to make this look really good, but it's a
great start.
Apparently this is a bug that slipped in when we started showing
normal users as deactivated in the user popovers: all bot users were
treated that way as well.
We'll want to do #7153 as a follow-up to get things fully working how
we want them.
If an organization doesn't have the EmailAuthBackend (which allows
password auth) enabled, then our password reset form doesn't do
anything, so we should hide it in the UI.
Previously, if you had the streams overlay open (but no active stream
clicked) while another user edited your subscriptions state, we'd
throw an exception handle the get_events call, because the code for
rerendering the subscribers list didn't consider the possibility that
there was no active stream.
The recent fixes we made to make stream settings update properly when
doing live updates were great, but they would throw an exception if
the stream settings overlay wasn't open. This fixes that by adding
the appropriate check.
We do not want the code to lead to a path where it will attempt to
display native notifications if the “Notification” object doesn’t
exist, as this likely means that the device does not support OS
notifications.
This imposes a maximum width constraint on the center block so
that it can maintain readability and keep the content paragraphs
to less than 1000px.
Fixes: #7092.
This shows the text "Never" for users who are part of a realm but
have never been active, rather than a more vague JavaScript output
of "Invalid Date" due to the fact that their last presence
evaluates to NaN.
When we added support for mentioning users when editing messages, we
neglected to add this bit of code needed to make sure the UI code in
message_list_view.js would actually rerender that part of the
message's state.
Arguably, this is a sign that the message_container structure should
be just recomputed every time we rerender messages, but that's a less
tactical fix.
The arrows were too close to the scrollbars that it would be
difficult to click them sometimes. This moves over the arrows and
unread counts to combat the issue.
Notifications essentially don't work on any mobile web clients,
so don't even show the banner.
This also fixes a traceback where it checks the permission state
with `notifications.permission_state()`, which calls
`Notification.permission`, which will error due to `Notification`
not existing on mobile devices.
Fixes: #7105.
This reverts commit f04981513b.
We're not sure, but we suspect that this made Zulip not show es for
folks using es_es as their locale. Further testing is required.
Tim Abbott
Brock Whittaker
Greg Price
Jack Zhang
Harshit Bansal
Catherine Kleimeier
Henrik Pettersson
derAnfaenger
Steve Howell
Umair Khan
Shubham Dhama