| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
| |
Currently keeping the same front end functionality of only reverting to
the original.
|
| |
|
|
|
|
| |
Fixes #2263.
|
|
|
|
| |
For mysociety/fixmystreet-freshdesk#16.
|
| |
|
| |
|
|
|
|
| |
confirmation page
|
|
|
|
| |
This reverts commit 6bc39892d7075fac79c0f40b2740de095535329d.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes mysociety/FixMyStreet-Commercial#1024.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
For mysociety/fixmystreetforcouncils#285
|
|
|
|
| |
reports
|
| |
|
|
|
|
| |
Fixes mysociety/fixmystreet-commercial#1016
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
Web and email template changes, CSS plus cobrand file with open311
config
|
|
|
|
| |
Add an update with each report closure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'updates are not sent to the council' message was incorrectly being
shown on reports where updates would in fact be sent. This was affecting
non-Bromley/Stevenage reports on fms.com and all cobrands using Open311.
This commit moves the logic out of the template and adds the
Problem->updates_sent_to_body method which inspects the receiving body's
Open311 configuration to determine whether updates will be sent.
The duplication of the Lewisham/Oxfordshire logic between Problem.pm and
send-comments isn't ideal but hopefully there won't be any new Open311
bodies that only send and don't receive updates. If there are we'll have
to look at refactoring that list.
|
| |
|
|
|
|
| |
Fixes mysociety/fixmystreet-commercial#925.
|
|
|
|
| |
Fixes mysociety/fixmystreetforcouncils#251
|
|
|
|
| |
An unneeded "END" was introduced in c7d98f98, sorry.
|
|
|
|
|
|
| |
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!
|
| |
|
|
|
|
|
| |
Add hook for post-title field content in report form.
Update translations.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically in UK cobrands, bodies have had IDs the same as the MapIt
area ID they cover. This can be confusing (if you are setting up a dev
environment, say) and should not be necessary. This commit removes the
requirement entirely, by switching any ID checks to either the name of
the body, or the actual area it covers.
One note: the body name in the test has to match so that we do not get
two bodies both covering 2237 created. This will not be necessary when
the tests are compartmentalized in the next commit.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This script can be used for the bulk closure of old reports that haven't been
updated in a long time.
Reports that haven't been updated in a *really* long time (since 2014, by
default) are simply closed, and those that haven't been updated since 2015 (by
default) are closed and an email explaining the closure is sent to the report
creator.
This script can be used for other cobrands, but they'll need an
archive.{txt,html} template in order for the emails to be sent.
For mysociety/fixmystreetforcouncils#51
|