| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
|
| |
Add a setting for the name of the image file used in the email header so
cobrands can override it
|
| |
|
|
|
|
|
| |
allows adding a logo_file setting in _color_overrides.html to change the
name of the file used. Defaults to email-logo.gif
|
|
|
|
|
|
|
| |
This is so a council could include the ref in other-* but not
alert-update if not wanted. Update Bucks to use new template
(not needed as it overrides for other reasons, but makes seeing
those other reasons in a diff easier).
|
|
|
|
|
|
| |
Try and include _council_reference always in other-reported, no need for
BANES other-updated, and include HTML version of a Bucks template so
that it is used.
|
|
|
|
|
| |
Currently keeping the same front end functionality of only reverting to
the original.
|
|
|
|
| |
Fixes #2263.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 6bc39892d7075fac79c0f40b2740de095535329d.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dcc5926 simplified the HTML email layout and styling, but introduced a
bug in Mac and iOS Mail (both of which use Safari to render emails)
where the central "column" of the layout would expand beyond its 620px
maximum width if your window/screen was big enough to let it.
As far as I can tell, this is a bug in Safari – it treats empty table
cells as if they aren’t there, meaning, in our layout, they no longer
"pushed" against the sides of the central column, allowing it to expand
to the full width of the parent (the window).
Adding a non-transparent background-color to the cells forces Safari to
handle them correctly, so we set a background-color that matches the
body background, to effectively make the cells invisible, while still
giving them enough "layout" to trick Safari into rendering them.
A fun quirk here is that, with the background-color hack in place,
Safari will no longer allow the cells to occupy zero width. Even when
the screen is the same width as (or narrower than!) our central column,
Safari ensures that the spacer cells maintain at least a 1px width,
resulting in a 1px dark grey "border" down the sides of the email.
Seems Safari won’t let you have it both ways – either the cells are
there or they aren’t ;-)
To avoid this "border", we only apply the background-color when we know
the window is wider than 620px. That way, the spacer cells will collapse
to zero width on narrow screens (because of the Safari bug) and will
expand to occupy the space you’d expect on wider screens (because of our
background-color hack).
Fixes #1928 (again).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 5px cellpadding on the wrapper table was resulting in 15px of white
space either side of emails when viewed on narrow screens. Which, on a
window that could be as narrow as 320px, is a lot of wasted space!
We only wanted the 15px of horizontal padding to be removed from the
sides of the "main" content, leaving the top and bottom "hints" with
some padding so that their text doesn’t crash up against the edge of
the window on narrow screens.
The easiest way to achieve this was to split the top and bottom "hints"
out into their own slightly wider tables, with built-in cell padding.
To make things simpler, the min- and max-widths are now stored in
variables, and the changes also meant we could simplify the media
queries controlling mobile breakpoints in modern email clients.
Fixes #1928.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This includes stopping some emails being sent (moderation, alert,
questionnaire), dealing with Open311/email report sending, and
tokenised_url.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Emails that contain a report’s title, description, and location in the
”sidebar” will now have a map that takes you to the report’s web page
when clicked.
Fixes #1596. Thanks to @MyfanwyNixon for the suggestion!
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows users who have the correct permissions to add reports on
behalf of the body or another user.
We enable editing of the email box by default, so that if JavaScript
isn't available, someone can still change the email for the 'another
user' option.
For mysociety/fixmystreetforcouncils#10 and
mysociety/fixmystreetforcouncils#11
|
| |
|
|
|
|
|
| |
One mail server we send to appears to reject messages containing =20,
even though those are perfectly acceptable quoted-printable messages.
|
| |
|
|
|
|
|
|
|
|
|
| |
HTML emails now have a white body background-color, so that
replies sent from Outlook (which inserts the reply message
inside the body of the original message) will have a white
background.
Part of #1469.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Design is all Zarino. This adds the ability to send HTML emails,
including attached inline images. When included, this is done as a
multipart/related email containing a multipart/alternative (of plain and
HTML) and any attached images, so that the images are available even if
HTML mail is not.
The alert emails list data has been improved so it can be constructed in
the templates rather than the code. Various templates have been tidied.
Various workarounds for email clients have been made, including:
* <th> is used so that the Android 4.x mail client can give them
`block` styling in the small screen media query.
* Font settings defined on every table cell (<th>) so that sans-serif
fonts are used in Outlook, rather than Times New Roman.
* A three-column wrapper table to create a 620px centred content area
that also shrinks down on narrow screens. (Outlook doesn’t like
max-width, so this is the simplest alternative.)
* Enforcing a sensible (500px) min-width for the main content area,
on clients that don’t support media queries (eg: native Gmail app).
* Giant borders on buttons so Outlook displays them
* Image alignment with align rather than float.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Historically, emails sent offline (alerts, questionnaires, etc) used a
different templating system from those sent by the website (e.g. login
emails), though the newer system was also being used for the site name
and signature of offline emails.
|
| |
|
|
|
|
|
|
|
| |
Newer versions of Email::Simple (2.104+) treat arrayrefs in headers by fetching
the first item only in scalar context. Our snapshot installs 2.102, so this
shouldn't be an issue, but we might as well bypass Email::Simple for those
headers.
|
|
|
|
| |
Fixes #1210.
|
|
|
|
| |
Fixes #1011.
|
|
|
|
|
| |
This is more friendly for e.g. copy and pasting by someone using the
Dynamics CRM software. Fixes #997.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- redaction marked with [...]
- of report and comments
- stores original data
- uses a single form, on the report/_main view
- requires additional permissions (user_body_permissions)
- Hide report functionality
- Moderation notification/contact form
- Moderation writes to admin_log
|
|
|
|
| |
And fix a couple that have redirected.
|
|
|
|
|
|
|
| |
Council redirects, BASE_URL comparisons, hard coded links, email
signatures
For #488
|
|
|
|
| |
And FixMyStreet.com specific open questionnaire page.
|