It looked like I got some hex values wrong during the
hsl to hex conversions. I used the built in vscode color
converter for this so not really sure how this happened.
The colors are now equalent to the original hex colors
before the conversion to hsl was made in
5869cc3b6d
As part of this change, we port into the .messages class the work in
4e8e7348da to change overflow-y to auto,
not scroll (skipping that would result in a regression).
Note that a pretty common use case for this is a realm admin sending this to
everyone after an import from HipChat or Slack. So this adds the realm_name
to the title (so that there is something they might recognize) and kept the
wording generic enough to accommodate the user not having clicked anything
to get this email.
Also strengthens the tests a bit to better test the complicated template
logic.
Apparently, when we renamed these files to no longer have a .txt
extension, we accidentally removed them from the set of strings for
translation, because `manage.py makemessages` by default only
processes .txt and .html files under the templates/ directory.
Fix this by adding a .txt extension.
This provides a nice user experience for folks where we do know what
their LDAP credentials are.
Though we need to fix#10917 before the content in the email with be
correct.
This adds a web flow and management command for reactivating a Zulip
organization, with confirmation from one of the organization
administrators.
Further work is needed to make the emails nicer (ideally, we'd send
one email with all the admins on the `To` line, but the `send_email`
library doesn't support that).
Fixes#10783.
With significant tweaks to the email text by tabbott.
This modifies the logic for formatting outgoing missed-message emails
to support the upcoming stream email notifications feature (providing
a new format for the subject, etc.).
We make some specific cases of tags use 2 space indents.
The case description:
* A tag with opening tag spread over multiple lines and closing tag
on the same line as of the closing angle bracket of the opening tag.
* A tag with opening tag spread over multiple lines and closing tag
not on the same line as of the closing angle bracket of the opening
tag.
Example:
Case 1:
Not linted:
<button type="button"
class="btn btn-primary btn-small">{{t "Yes" }}</button>
After linting:
<button type="button"
class="btn btn-primary btn-small">{{t "Yes" }}</button>
Case 2:
Before linting:
<div class = "foo"
id = "bar"
role = "whatever">
{{ bla }}
</div>
After linting:
<div class = "foo"
id = "bar"
role = "whatever">
{{ bla }}
</div>
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)
Vishnu Ks
Rishi Gupta
Abhinav Singh
Tim Abbott
Raymond Akornor
Roger Souza
Cynthia Lin
Akash Nimare
Shubham Dhama
Anupam Dagar
Aditya Bansal
Sarah
Yago González
YJDave
Shreyansh Dwivedi
Umair Khan
Steve Howell
Brock Whittaker
Vaida Plankyte
Harshit Bansal
James Rowan
Aditya Ramesh
Vaida Plankyte
Benjamin Gilbert
hollywoodno
Rishi Gupta