It's kind of awkward that this takes the scheme-relative URL -- either
the full URL, or maybe just the host, would make more sense. But on a
bit of study of the plugin's source, I can't convince myself that it
won't break if given the full URL with the scheme. (See a code
comment thread in #7116.) So leave the substance as is, pending the
plugin itself getting some cleanup, but do fix the sentence's English
grammar since we're looking at it.
This was apparently completely broken for some time, and got a bit
worse with my recent changes (enough to fail a test).
Since the plan for this page likely involves dissecting and
eliminating it, I think it makes sense to just fix it hackishly and
move on.
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.
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.
Tweaked by tabbott to have the field before the invitation is
completed be called invite_as_admins, not invited_as_admins, for
readability.
Fixes#6834.
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 effectively implements the feature of default stream groups,
except for a UI, nice styling, etc.
Note that we're careful to not have this do anything in an
organization that doesn't have any default stream groups.
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.
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.
Making the same point (that you can configure the notifications in
settings) at both steps felt pushy. I think the first prompt is
actually best kept to a minimum of words, so leave that one with
just the ask.
In the second step, try an active pitch. This could go either way, or
be any number of other messages, but the settings line felt a little
defensive to me, like it was suggesting that our notifications would
be noisy and here's a way you can try to mitigate that. I think with
our default settings (and in an org with mostly-reasonable humans, but
even a large and busy one) they're actually not at all noisy; and if
we learn of situations where that's not true, we'll work to fix that.
So, try this line instead.
A style note: I chose "your team" here to refer to the people the user
communicates with in their organization. We consistently say either
"organization" or sometimes "realm" for the concrete thing in the
product that is the whole universe of streams and users, etc., that a
given account lives in; but that feels too formal here. Conversely,
one reason we don't say "team" for an organization is that it feels
too cozy and small, more appropriate for 8 people who interact every
day than for 80 or 8000 people; but this line is mainly about those
8 people even if the organization has 8000. There are some examples
of this already in the codebase; see `git grep -w team`.
i18n note: These passages of a couple of connected sentences should
generally be marked for translation as one message, not several
separate ones. That helps the translator be sure of the context so
they can translate appropriately. For example, in the second prompt
in this version, there's an implicit "because" relationship between
the two sentences, and in some languages (I'm 90% sure this is true in
Japanese), it would be weird to leave it implicit and the second
sentence should contain the equivalent of "That's because".
This presents multiple states for the subdomain input option
depending on the existence of a root domain.
Commit modified heavily by Brock Whittaker <brock@zulipchat.com>.
Fixes#6863.
I think an hour after signup is not the right time to try to get someone to
re-engage with a product.
This also makes the day1 email clearly a transactional email both in
experiencing the product and in the eyes of various anti-spam laws, and
allows us to remove the unsubscribe link.
The rules here are fuzzy, and it's quite possible none of Zulip's emails
need an address at all. Every country has its own rules though, which makes
it hard to tell. In general, transactional emails do not need an address,
and marketing emails do.
This is a two-step notifications process that will ask a user
to enable notifications and if they click exit give them three
options:
1. Enable notifications.
2. Ask later.
3. Never ask on this computer again.
The first two are self-explanatory (ask later = next session it
asks again). The third is captured and stored in localStorage and
a check is done on page load to see whether or not notifications
should be displayed.
Commit modified heavily by Brock Whittaker <brock@zulipchat.com>.
Fixes#1189.
We swapped the function of these hotkeys, but forgot to update these:
* left_sidebar: Update hotkey to 'q' in filter stream option title.
* right_sidebar: Update hotkey to 'w' in search people option title.
Greg Price
Tim Abbott
Brock Whittaker
Jack Zhang
Rishi Gupta
Harshit Bansal
Henrik Pettersson
Vishnu Ks
derAnfaenger
Cynthia Lin
Sumana Harihareswara
Aditya Bansal
Alexis La Porte
Aastha Gupta
akashnimare
Vishwesh Jainkuniya