| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
|
|
| |
Since questionnaire responses were recorded on email link click, we
should have been showing those that reopened or fixed reports, not
just steady-state "Still open" ones.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Previously, CSS was absolutely positioning one on top of the other.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Simplify markup required for the status banner.
* Simplify styles - the banner is now identical on all screen sizes.
* Move the banner from `report/display.html` into `report/_main.html`
so that it can appear after `.problem-back` in the source order.
* Use real pin icon instead of `pin-flat-white-small.png`.
* Set a default `$col_fixed_label` colour in `_base.scss`, so cobrands
don’t have to define it themselves if they’re happy with green.
* Introduce `$col_fixed_label_light`, with a sensible default for all
cobrands, even ones that have a custom `$col_fixed_label`.
* Remove `$col_fixed_label_dark` – no longer needed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
With the recent login changes, the user form was being hidden after
logging in while leaving an update, meaning you had to click "Continue"
to see the thing it was asking you to check. Refactor the update flow
slightly in this area to be more like reporting, showing the relevant
bit of the user form immediately (and thus also not having it within a
hidden section).
|
|
|
|
| |
All templates call private_details.html, which uses this variable.
|
|
|
|
|
|
| |
When a report is pulled in via ajax, it means there are then two sets of
login flow buttons on the page, and the JS setup only attaches to the
first of these.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This moves the email input from `user_loggedout.html` closer to the
password inputs in `user_loggedout_{by_email,password}.html`, because
we want to emphasise the connection between your login email/username
and your password, and, now that only one "Yes I have an account / No
I do not have an account" fieldset is displayed at a time, there was
no reason to ask for the email/username up front.
This, however, now means the form includes two username inputs, so:
* `Report/New.pm` and `Report/Update.pm` now pick the first non-empty
username param and use that.
* `user_loggedout_email.html` now expects a `name` parameter, so that
we can give the two username inputs unique ids in the markup.
Also:
* The "optional" phone and email inputs in user_loggedout_by_email.html
are printed *after* the main username input if SMS login is enabled
(since one or other of them is unhidden by javascript, based on
whether you entered a phone number or and email address into the
"username" input, and it would look weird to have an input become
unhidden *above* the input you’re currently editing).
|
| |
| |
| |
| | |
Co-authored-by: Zarino Zappia <zarino@mysociety.org>
|
| | |
|
| |
| |
| |
| |
| |
| | |
This was a cute space-saving feature at the time, but the layout made it
look like the button was specific to that input, rather than submitting
the whole form. Make similar buttons full width, and improve spacing.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Remove update/form_name.html template.
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
Currently keeping the same front end functionality of only reverting to
the original.
|
| |
|
|
|
|
|
|
|
|
|
| |
use the bodies array of reporting_data to check if there is council
specific javascript validation and, if so, load that into the JS
validation rules.
This does mean we reset the validation rules each time you select a
category.
|
|
|
|
|
|
| |
`report_check_for_errors` now fetches the cobrand for the current report
and, if present, runs `report_validation` method from cobrand over the
report.
|
|
|
|
|
|
|
| |
If set then when the user creates a new body report it will prefill the
report title and description with some basic text.
For mysociety/freshdesk#23
|
|
|
|
|
|
|
| |
If a user has this permission then the report_as dropdown will
default to reporting as the body.
For mysociety/freshdesk#23
|
|
|
|
|
|
| |
This changes the projection from EPSG:3857, which is not included in the
bristol openlayers build, to the identical EPSG:900913 which is, so that
the conversion happens.
|
|
|
|
|
| |
Do not hide the report form if you click on a non Bucks road that is
managed by Highways England.
|
|
|
|
|
|
|
| |
Includes an option to send to the council instead for e.g. reports on
underpasses or bridges.
Fixes #736
|
| |
|
|
|
|
|
|
|
|
| |
Allows user's to see the inspector panel to mark reports as Private, and
also to view those non-public reports. Useful for call centre staff who
want to record private reports but don't need to other permissions.
Fixes mysociety/fixmystreet-commercial#1213
|
| |
|
|
|
|
|
|
|
|
|
| |
The intention of .btn--block is to make the element full width. Because
of the weird way browsers handle sizing of form elements, just setting
`display: block` on `<button>` and `<input type="submit">` elements
wasn’t making them full width. Instead, .btn--block needed to explicitly
set a 100% width, and then reset any margins or box-sizing issues that
might cause it to overflow its parent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the "Report a problem" link in the nav bar links, more often
than not, to the reporting form rather than the homepage, it could be
challenging to actually start a new report in a location *other* than
the one currently on screen.
Rather than adding a link to the homepage, this change hopefully adds
a link right at the moment the user expects it – right on the "Report
a problem" form.
It also gave us an opportunity to reword the "Wrong location" message
and give it an icon more suitable for high-dpi displays.
Fixes #2238.
|
|
|
|
| |
This reverts commit ee3c4e05daf3f4df01762ead3d07697a12f13a28.
|
| |
|
|
|
|
|
|
| |
do not use details directly from user object because in the slim chance
that the user has phone and email verified and there is a failed email
login we display the phone number from the database.
|
| |
|
|
|
|
| |
disable, enable and delete for user alerts on user_edit page
|
|
|
|
|
| |
Include a list of alerts the user is subscribed to at the bottom of the
user_edit page in the admin.
|
|
|
|
| |
Also, remove top of page link that was hardcoded to a now missing page.
|