- add get/post view
- create a pdf upload form
- add a template where user can upload the file
- check boundaries of the letter by calling template-preview
- display banner messages with boundaries validation result
- display pages of the document, with visible boundaries overlay
if the document did not pass validation, and without overlay
if they do pass validation
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
Minor changes to the number formatting for the `/platform-admin` page to
- Show the complaint percentage to 2 decimal places. (The number of
complaints is often below 0.0% so 1 decimal place isn't useful)
- Format the numbers in the status boxes to use a comma as a thousands
separator.
This is the existing behaviour. It’s broken by this issue in WTForms
2.2.1: https://github.com/wtforms/wtforms/issues/401
This commit hand-crafts the default value, because WTForms is ignoring
the `default` argument on the form object attribute.
Not really sure how this ever worked 🤔
We had kept the original platform-admin page at `/platform-admin` and
created a new page, `/platform-admin-new` for the new platform admin
page. Now that the numbers on both pages look ok we no longer need both
pages, so can replace the original page.
Check that the format of the dates entered is in the `YYYY-MM-DD` as
specified and show an error message if it is not. If the date was not in
the specified format, there would be no error message but the content of
the page would change which was misleading.
In API, the endpoint for the new platform admin stats page has been
moved to a platform stats blueprint. This means we now need a platform
stats client.
Added a new platform admin page, at '/plaform-admin-new' which shows
different data. This no longer offers the option to filter by test-key,
only by date, and also gives a more detailed break-down of the
notifications and failures sent with a normal / research key.
The existing platform admin stats page ('/platform-admin') has not been
deleted yet so that both pages can be compared.
A new platform admin page Email complaints has been added to surface those complaints.
Eventually the complaints will be visible to the services so they can remove the email address from their mailing list.
Next thing to implement is "x email complaints" warning on the platform admin summary page.
platform_admin is a separate concept to permissions, so by removing the
checks for it from the current_user.has_permissions function, we can
simplify things greatly. We already record on the user whether they're
a platform admin anyway.
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
Turns out the counts were all showing as zero because the generator had
already been consumed by the time we were trying to do the stats. Making
it a list comprehension means it can’t get exhausted.
We have two new pages for live and trial services that:
- are faster loading
- are now linked to
So the list of services doesn’t need to be on the platform admin index
page any more.
We have a lot of services now. Mostly we want to look at what live
services are doing. So loading up the trial mode services every time
slows things – generating, rendering and using the page – right down.
This commit adds two new pages, one to view only live services, and one
to view trial mode services.
This page currently includes all notifications for all services, including
those sent using a test key. Stats on all other pages exclude test key usage,
though, which can lead to confusion for admins comparing numbers between
pages. Adding the option to toggle between including and excluding test key
usage on the platform admin page gives context for this difference, and allows
admins to see live usage of the platform as well as load associated with test
key usage.
* all current invocations of get_services now call get_active_services
EXCEPT for platform admin page (where we want to see inactive services
* cleaned up parameter names and unpacking (since *params is unhelpful)
* fixed incorrect kwarg name in conftest
Other than which services are live it’s also interesting to know what
services are getting created on Notify. So let’s put the newest ones at
the top of the page.