We now include whether the message was a private or group private
message; this is particularly important with the new setting to
disable including any message content in these emails (since in that
case, one doesn't know anything about the message types).
In this commit we add support for some tags which are also called
void-elements according to
http://w3c.github.io/html/syntax.html#void-elements to be parsed by
our template parser and get tagged as singleton_html_tags.
Fixes: #8387.
This was basically rewritten by tabbott, because the code is a lot
cleaner after just rewriting the ZulipPasswordResetForm code to no
longer copy the model of the original Django version.
Fixes#4733.
The CSS linter was pretty hard to reason about. It was
pretty flexible about certain things, but then it would
prevent seemingly innocuous code from getting checked in.
This commit overhauls the pretty-printer to be more composable,
where every object in the AST knows how to render itself. It
also cleans up a little bit of the pre_fluff/post_fluff logic
in the parser itself, so comments are more likely to be "attached"
to the AST node that make sense.
The linter is actually a bit more finicky about newlines, but
this is mostly a good thing, as most of the variations before
this commit were pretty arbitrary.
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 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.
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.
Not sure why we have `overflow-y: scroll` in `messages` container in
missed messages email template when it is not a fixed width container
but anyway changing it to `overflow-y: auto` seems to be a safe change
as it will remove the ugly looking inactive scrollbar that was being
displayed there besides the `messages` container without changing the
functionality(if any).
About to add another template for digest and missed message emails. Another
natural name would be email_base_transactional, but the followup_day{1,2}
emails aren't really transactional.
For almost all of these, the verbose support offer clause is almost the same
as the non-verbose version. The distinction carries extra carrying cost when
coming up with new copy, testing new email designs, etc.
Make sure 's, &s, and other characters are not HTML-escaped in subject
lines and plain-text emails.
Hack so that this isn't blocking the release of Zulip 1.6. A more robust way
to do this would be to have two different template Engines, one that renders
HTML, and one that doesn't.
Fixes#5088.
Now, in the event of messages between two other members of a huddle,
the missed message emails are threaded in "Group PMs with name1 and
name2" and not in separate threads by sender.
Also, now the order of recipients in get_display_recipient consistent
with the order of names that appears in the list of personal messages
on the left sidebar.
Fixes most of #4553.
The only thing being translated in any email was the title of the Zulip
header image in the html file, probably because not doing so breaks a linter
rule.
he name "Zulip" doesn't make sense to translate anyway.
This adds helpful email notifications for users who just logged into a
Zulip server, as a security protection against accounts being hacked.
Text tweaked by tabbott.
Fixes#2182.
In response to feedback that joining (and sending a first message to) a new
chat platform/org is already intimidating enough, and "Not Recommended" gets
the point across in a gentler way.
The policy here is essentially:
* Pages on the central server (documentation, etc.) are server_uri.
* Pages associated with a user's realm server (anything logged-in, plus
things like their login page) are realm_uri.
Helps in case the development environment is not using https.
We get the value from zerver/context_processors.py (which is
ultimately reading it from settings)
Tim Abbott
YJDave
Vishnu Ks
Aditya Bansal
Rishi Gupta
Shreyansh Dwivedi
Umair Khan
Steve Howell
Brock Whittaker
Vaida Plankyte
Harshit Bansal
James Rowan
Aditya Ramesh
Vaida Plankyte
Benjamin Gilbert
hollywoodno
Rishi Gupta
Tim Abbott