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.
This allows CSS to discriminate by platform and show particular
content; in this case showing things with the attribute
[if-zulip-desktop] content only on “ZulipElectron”.
This makes the developer experience of the /emails pages significantly
cleaner, since you don't have to look at both the HTML and the text
for each message at the same time.
Fixes#6844.
This was a not-well-thought-through behavior change done in #6489; the
part that was actually a problem was ctrl-enter not producing spaces
anyway.
So we fix this, and also add a comment explaining why.
Fixes#6908.
The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
Rishi Gupta
Harshit Bansal
Brock Whittaker
Henrik Pettersson
Vishnu Ks
derAnfaenger
Cynthia Lin
Sumana Harihareswara
Tim Abbott
Aditya Bansal
Alexis La Porte
Greg Price
Aastha Gupta
akashnimare
Vishwesh Jainkuniya
amanharitsh123
Eeshan Garg