| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If the Open311 endpoint provides the external_status_code field
in servicerequestupdates.xml output, it’s stored in each comment’s
extra field as well as the problem’s extra field. This will make it
possible to trigger response templates based on this value.
|
| |
|
|
|
|
|
|
| |
The Cypress docs suggest putting machine-specific config into a
`cypress.env.json` file at the same location as `cypress.json`.
(For example, if you want to disable video recording of test sessions
on your machine, but not everyone else’s.) Since this file will be
machine-specific, we don’t want it tracked in Git.
|
| |
|
|
| |
Fixes mysociety/fixmystreet-commercial#943.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
| |
fixmystreet.com went down early Sunday morning because the database server had
been upgraded in the past year and was now set to UTC and not local time. This
confused the codebase when it encountered timestamps that could not exist, all
between 1-2am UTC.
Ideally, timestamps in the database should be 'with time zone' or be stored in
UTC, but for now let us set the time zone to the local one upon connection.
|
| |\ |
|
| | |
| |
| |
| |
| | |
Upgrade Test::PostgreSQL, which fixes a bug delaying the end
of test running, and introduces a nicer setup mechanism.
|
| |\ \ |
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The "coerce pin ID to integer" behaviour to fix a previous issue was
coercing undefined to NaN, which then caused other problems with the
new report pin, such as fading out when hovered, and being the wrong
size.
Also improve the cursor handling, showing the grab/ grabbing cursors
where available.
|
| |/
|
|
|
|
| |
If you started a new report by clicking the map before the
server had responded with the map list pins, when they did
arrive they would replace the new report pin.
|
| |
|
|
|
| |
We do need to store them, so that the sending knows which fields are being
requested, but we do not want them output to the client at all.
|
| | |
|
| |
|
|
|
|
| |
If the map was not clicked and we don't have a postcode we should still
send the easting and northing extra attributes if send_notpinpointed is
set.
|
| |
|
|
|
| |
Give some feedback to people who try to submit the homepage form
without first entering a location to search for.
|
| | |
|
| |\ \
| | |
| | |
| | | |
'2016-uk-green-banner-position-test' and '2021-uk-homepage-intent-experiment'
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Present "report" vs "browse" choice at time of postcode entry, so we
can track intent, as part of a temporary experiment into what people
expect to see on the fixmystreet.com/around page.
Google Analytics will be able detect which button was pressed by
looking for the `intent=report` or `intent=report` query string param
in the resulting pageview location.
We supply a *third* submit button, immediately before the other two,
and hidden from visual users and assistive devices, to prevent either
of the "intent" submit values being sent when the user submits the
form via the Return/Enter key.
Part of #2021.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
On PRs from external forks, it won't be.
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Store if the report/update was created by someone using the contributed-as
dropdown, and use that information to perhaps not send report-sent emails.
|
| | | | |
| | | |
| | | |
| | | | |
Part of #2016.
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Data collected by #2001 has shown that some people are clicking the big
green "Click map to report a problem" banner on fixmystreet.com/around.
We assume the same is true for other cobrands.
As suggested in #2016, this commit adds a click handler to that banner
element, which will begin a new report at the centre of the screen. It
might not be the exact right location, but the pin can be repositioned
from the /report/new form, and beginning a report is better than just
soaking up the click and doing nothing.
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
I don't think this check could ever have worked, because items are invisible
if their parent is set to `display: none`, so it would hide the links bar if
it was already hidden, and show it if it was already shown.
Use a js- class for the movement of the feed item into the sub map links.
|
| | | | |
|
| |/ /
| |
| |
| | |
Then it can skip working out some things as they are not needed.
|
| |/
|
|
| |
The change to base in fc172603 affected the layout display.
|
| | |
|
| |
|
|
| |
The code now uses this translation as the hard-coded way was removed.
|
| |\ |
|
| | |
| |
| |
| | |
This fixes #2023 by removing the comma.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
Add a per body configuration option to allow Open311 updates to contain
only a status change, rather than emitting a warning when this happens.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is part of the integration with our open311-adapter. The automated
property indicates that it's an expected value but either it's going to
be set by the server, or appear as a hidden field.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per cobrand configurable option to send multiple photos over open311
instead of just a single one. Does this by sending multiple media_url
parameters in the POST body.
The default remains to send the first photo associated with a report.
|
| | | |
| | |
| | |
| | |
| | | |
Web and email template changes, CSS plus cobrand file with open311
config
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This enables the display of existing reports from the back end on FMS
if the body is configured to do this.
Reports will not be created if they are missing an id, a lat or a long,
if the lat/long is outside the area covered by the body, if there is
already a report with a matching id, or if we can't parse out the
request time.
|
| | | | |
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| | | | |
|
