| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
|
|
| |
- is set to 0 on state change within time-limit
- is set to 1 on state change after time-limit
- only marks overdue on first time
|
|
|
|
|
|
|
| |
mysociety/FixMyStreet-Commercial#459 - we move "confirmed" to being
a moderated-but-not-complete state, and run the check for ->overdue
also on changing status from 'unconfirmed' (but only the first time,
so only if $extra->{moderated_overdue} isn't already set.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
see mysociety/FixMyStreet-Commercial#459 - "a report is moderated as
soon as its state has changed for the first time from Erfasst (en:
Submitted / db: unconfirmed) to any other state."
Thus we move 'confirmed' problems from the 1-day moderation SLA, to
a 5-day one, with $include_parent unset (e.g. as with 'planned' it
is with the DM, so doesn't need to be sent to the parent body also.)
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Omitted the credits and links to further information.
|
| | |
|
| |
| |
| |
| |
| | |
Use the internal hash URL of the photo so that it can still be seen in
the admin interface.
|
| | |
|
|/
|
|
|
|
| |
Reduce magic numbers by switching fixed width to a margin elsewhere.
This has the added bonus of making the 'middle-width' .content
have a pleasing right margin.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a body has been marked as deleted (currently only exposed in the
Zurich cobrand's admin) the categories for that body should not be
available on the report_new form.
Prior to this change there was an error running the
'zurich-overdue-alert' script, because it wasn't expecting the
'bodies_str' field to have any entries in the format 'x|y,z', this
prevents this problem from happening in the future (though it doesn't
fix any existing entries with this issue).
|
|
|
|
|
|
|
|
|
| |
If the ALLOWED_COBRANDS configuration variable only contains one entry
(and also work if it's a string rather than a list), always use that
cobrand, no matter what the hostname is.
The example Vagrantfile no longer needs the configuration changes at
all.
|
| |
|
|
|
|
| |
Use a relative URL in the CSS in case it's proxied.
|
|
|
|
| |
Graphic and css from FMT. Fixes #579.
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
This fixes the map so the centre is offset to the right to account for
the overlayed sidebar on the left.
|
|
|
|
|
| |
The staging banner didn't fit, and .wrapper{position:relative} was breaking things :-(
Easier to keep it simple, drop the header and just set the title in the Cobrand module instead.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
splits emails on comma
WIP
|
|\ \
| | |
| | |
| | | |
https://github.com/andylolz/fixmystreet into andylolz-389-report-search-ref
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #389
|
| |/
|/| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The position:fixed bottom navigation does not stay fixed in Chrome, it
appears to scroll with the content (though the link targets remain and
swapping tabs fixes the display, so I'm pretty sure it's a bug). The bug
is logged in Chrome's tracker at:
https://code.google.com/p/chromium/issues/detail?id=311513
To work around it, the z-index has been removed from .container; this
would mean that the sidebar notes all disappeared under the map, so they
have been jigged to appear on top of the main content div instead.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This fixes #527.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This caused issues with the comment.problem_state column constraints
when running on the vhost as some problems were marked as hidden
(under normal circumstances you can't add a comment to a hidden
problem). Because this column is nullable we simply don't add it
to avoid this issue.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The phone number was made mandatory in #541. To make this change
compatible with older versions of the mobile app I've had to drop
server side validation of the phone number for requests that come in
from mobile apps.
To determine if it's a mobile request I'm checking the 'service'
parameter in the request, which is only set in requests from the mobile
apps [1].
The phone validation will still happen client side for the newer
versions of the app, and the web app will continue to work with the
server side validations.
[1] https://github.com/mysociety/zurich_mobile/blob/1fec2bc21dad9326819105cdbf5d47183e7503ba/www/js/models.js#L75
|