| Commit message (Collapse) | Author | Age | Lines |
|\ |
|
| | |
|
|/
|
|
|
|
| |
Add options to set the cobrand plus related options for co-ordinates,
name and area id to the browser test command. Set BASE_URL to same as
test server, as that is used in e.g. list link output.
|
|
|
|
|
|
|
|
| |
Including testing the filters, viewing a report, and pushState.
Plus a mock MapIt handler for returning a GeoJSON outline, to make the
page load. The BASE_URL is also set to the same as the test server, as
that is used in list link output.
|
|
|
|
|
| |
The existing fixture script generates random results so is no use for
front end testing.
|
|
|
|
|
| |
but only send if the problem as a customer reference and use that as the
external id reference
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a script for loading cobrands into an instance of the
FixMyStreet Docker container.
A directory containing the necessary module, templates, css, etc
should be mapped into the container at `/var/www/fixmystreet/cobrand`
and activated by adding the cobrand to `ALLOWED_COBRANDS` as usual.
See the documentation at https://fixmystreet.org/install/docker
for more details.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes four containers: app, memcached, nginx, and postgres.
The preinit script is used at container startup to ensure the database
is initialised. Includes a volume for the Postgres database to permit
persistence. Also sets the `PGDATA` variable to a subdirectory to
support optional use of a filesystem mount.
The repo/branch can be specified at build time.
If `SUPERUSER_EMAIL` and `SUPERUSER_PASSWORD` are set when the FMS
container starts the preinit script will pass these to
`bin/createsuperuser` when it starts up. These have been set to test
values in the supplied Docker Compose configuration.
Reverse proxy issue
===================
If nginx and fms were on the same machine, ReverseProxy would
automatically be in use, but via docker containers they are not. Do we
need to force it to be switched on? Let's see. There are four possible
options, with their outcome:
* port not in Host, ReverseProxy not in use
Anything using the automatically-generated base instead of BASE_URL uses
port 9000, meaning those links don't work.
* port not in Host, ReverseProxy in use
Anything using the automatically-generated base instead of BASE_URL uses
port 80, meaning those links don't work (they would if you had
docker-compose listen on port 80, being then a similar situation to e.g.
the AMI image).
* port in Host, ReverseProxy not in use
This works *unless* the port is 80, just to be contrary to the above; in
that case it is stripped and :9000 is put back on, meaning those links
again don't work. I realise we use 8000, but would be confusing if
someone tried it out.
* port in Host, ReverseProxy in use
This works in all scenarios, and thus is what we go with.
|
|
|
|
|
|
|
| |
- Adds support for additional variables intended to control when to
install postfix and postgres.
- Skips nginx setup and integration when performing a docker build.
- Don't print usage during docker build
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 6bc39892d7075fac79c0f40b2740de095535329d.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The inactive report script can mark matched reports as closed for updates.
This removes the update form and signing up for updates from a report page.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Some Open311 servers will refuse an update with a
timestamp earlier than one it already received.
|
|
|
|
| |
Otherwise we may not warn on otherwise skipped updates.
|
|
|
|
|
|
|
|
|
| |
Previously send-comments errors would only be printed the first time
they occurred so there was no visibility of ongoing errors. This brings
send-comments in line with send-reports by emitting errors if the script
is called with --verbose.
Fixes #2091
|
|
|
|
| |
Adds and extra column for bodies and the associated Extra role.
|
| |
|
| |
|
|
|
|
| |
Also adds script for fetching the last 24hrs of reports
|
| |
|
|
|
|
|
| |
For controlling if reports pulled in via Open311 should have the
position converted from Easting/Northing to lat/long.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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 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.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
The Zurich code was written a long time ago, and used overriding so that
e.g. the hard-coded 'investigating' state referred to Wunsch (wish). Now
that states are stored in the database, we can create ones specially for
Zurich and use them instead. Hooray!
|
| |
| |
| |
| | |
Remove old unused setup-contacts code, superceded by fixtures.
|
|/
|
|
| |
Add an update with each report closure.
|
| |
|
|
|
|
|
| |
This also can set up users so that the admin
"Log user out" function works correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bristol's Open311 endpoint still seems to be returning empty metadata
for some services that claim to have metadata. They have made changes to
their published services since the change was made to exclude their
endpoint, which is causing issues for new reports.
Rather than exclude their endpoint entirely from being updated, this
commit just silences the noisy error message for Bristol.
Reverts the change made in 491eb26e4.
|
| |
|
| |
|