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.)
This section has the docs a new admin might look at during initial set up.
Does not add or remove articles, just moves stuff around on the
sidebar. Does remove the "Miscellaneous" section.
Collects all relevant docs into "Sending Messages" and "Reading Messages".
Doesn't add or remove any docs, just moves them around on the sidebar.
Duplicates "Message a stream by email" (it now appears in two sections)
Removes the "Editing Messages" section/header.
This section should be the stuff we want users to see when they are first
setting up their account.
This commit only moves links on the sidebar around, no additions or
deletions.
This changes the "Server" and "Account" attributes in the info log
to render links so that they are guaranteed to have our styling
and behavior across all email clients.
Create a new custom email backend which would automatically
logs the emails that are send in the dev environment as
well as print a friendly message in console to visit /emails
for accessing all the emails that are sent in dev environment.
Since django.core.mail.backends.console.EmailBackend is no longer
userd emails would not be printed to the console anymore.
This removes the underline on hover and changes the text to get to the
index.
This also changes it to an <h2> tag so that it will be more inline
with the styling of the rest of the sections, but without the
down chevron.
Some email services will provide default styling for things like
buttons, and in this case the site created a style that had a
`background` attribute that overrode our `background-color` attribute
because of CSS importance heirarchy. This swiches us to use
`background` as well.
This also forces no `text-shadow` on buttons.
Fixes: #6775.
This adds a max-width constraint to the hero content so that the images
inside the hero don’t keep expanding forever and eventually outside of
the hero’s bounds.
Fixes: #6713.
This deserves a fact-check to make sure I haven't simplified
anything past what's true! Note in particular the TODO comments.
Especially in particular, I took out references to the .zip installer
for macOS and the .deb installer for Linux. I couldn't tell in what
situation we'd really want to steer a user toward them (and wouldn't
recommend instead either the .dmg installer, or the apt or AppImage
instructions, respectively), so taking them out simplifies the
instructions and avoids presenting the user with a choice they have no
context for making. But if there is such a situation, then we can put
them back.
This shows the download instructions only selectively based on
whether the device has download instructions for it. This means
currently it shows the page for Windows, Mac, and Linux.