The alt text of the leading images were displayed as preview
content in inbox by email clients like gmail. Since the leading
images were used mostly for decoration this made the preview
content gibberish. It's fine to set the alt attributes to empty
from accessibility point of view since the old alt attributes
did't added any meaningful information.
Hopefully this does a better job of spurring people to action, and also
suggests a self-service fix if they don't (i.e. contacting the person that
invited them).
Making sender name go in-line with message body only if
the html starts with <p> tag since it won't look good
if the message starts with a code snippet, ul, etc.
If message starts with p tag we can safely assume that
it can go in-line with sender name.
This is a dramatic redesign of the look and feel of our missed-message
emails, designed to decrease the feeling of clutter and just provide
the content users care about in a clear, visible fashion.
This cleans up the reply_warning feature in favor of a more coherent
explanation of whether or not one can reply.
(Also, critically, it now advertises the ability to enable
missed-message email replies with some administrative configuration
work.)
The antialiasing decisions we made for the webapp should be constant
over the entire page, not limited to particular subsections or themes.
If we wanted antialiasing, we should do it on the entire page, not
individual random widgets. But it's not clear we actually want to do
it on the entire page. The `-moz-osx-font-smoothing: grayscale`
setting now happens by default in OSX Mojave (40% world market share
right now and growing), so there's no reason to override it. And
without retina displays, generally, subpixel rendering provides better
results than antialiasing (which overrides subpixel rendering).
Thanks to Anders Kaseorg for advice on this issue.
Refactoring in 4e1c058 was not correct since recipient_block
and message_content checked for if not condition while
recipient_header checked for if.
The naming of classes in 6077a33 was also not correct
semantically.
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.
Vishnu KS
Tim Abbott
Rishi Gupta
Mateusz Mandera
Soumya Himanish Mohapatra
Puneeth Chaganti
Vit Rozkovec
anhhuynh
Abhinav Singh
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