We don’t really want you modifying lines of the address after you’ve
entered it. Especially when it might not be obvious that modifying the
address line placeholder will modify the address you’re sending the
letter to.
Optional address placeholders aren’t a thing for one-off letters any
more, so we can tidy up the code a bit by removing the parts of the flow
that are accounting for them.
If you have an placeholder from the address block elsewhere in your
letter then you currently get redirected to the address block page
instead of being offered to fill that placeholder in. This commit
tightens up the check to only do this when the placeholder is in the
first 7 placeholders, which is where we store the address placeholders.
We had a report that when clicking on the 'Download this letter' link on
the notification page the file was not being downloaded as a PDF file
but was given a `.htm` file extension instead. We should be able to stop
that happening by using Flask's `send_file` function with the right mimetype.
This change updates the `view_letter_notification_as_preview` to use
`send_file` and splits out code to get the file data into a separate
function.
Mocks in the tests have been updated and some unused mocks removed.
As part of making the API call we extra the recipient from the first
line of the address. This code was assuming that the recipient would
always have the key `address line 1`, but we’re no longer guaranteeing
that it will be capitalised and spaced exactly like that.
We’re doing this everywhere else now, so this completes the story.
It uses the same regex as elsewhere and the error messaging is
consistent (but not uniform) with the other places.
Since we’re doing normalisation and line-count-checking of addresses in
multiple places it makes sense for that code to be shared. Which is
what happened here:
https://github.com/alphagov/notifications-utils/pull/713
This commit refactors the admin code to make use of the new utils code.
Note about placeholders:
- they now go into the session as `address_line_1` instead of `address
line 1` because this is the format the API uses, so should be
considered canonical
- they are now fetched from the session in a way that isn’t sensitive
to case or underscores (using the `Columns` class)
- the API doesn’t care about case or underscores vs spaces in
placeholder names because it’s checking an instance of `Template` to
see if all the required placeholders are present (see
401c8e41d6/app/notifications/process_notifications.py (L40))
A lot of pages in the admin app are now generated entirely from Redis,
without touching the API.
The one remaining API call that a lot of pages make, when the user is
platform admin or a member of an organisation, is to get the name of
the current service’s organisation.
This commit adds some code to start caching that as well, which should
speed up page load times for when we’re clicking around the admin app
(it’s typically 100ms just to get the organisation, and more than that
when the API is under load).
This means changing the service model to get the organisation from the
API by ID, not by service ID. Otherwise it would be very hard to clear
the cache if the name of the organisation ever changed.
We can’t cache the whole organisation because it has a
`count_of_live_services` field which can change at any time, without an
update being made.
It was saying ‘16 hours ago’ instead of today. This is because, in
strftime:
- `%M` means minute, not month
- `%D` means short MM/DD/YY date, not day of the month
The test wasn’t catching this because the freeze time and mocked value
from the API were set to the same minute.
if someone starts a new one-off flow they'll get taken to the address
page. However, if someone hits the back button, they'll cycle backwards
through placeholders and will end up on the individual line pages. Lets
redirect them to the correct place.
We'll additionally need to reconstruct the address block from the
various session variables that may or may not be populated
rather than in multiple placeholders - this is the first step towards
making postcodes non-required, which is the first step towards
international letters.
they still populate address_line_# and postcode fields under the hood -
to keep validation working the same, the last line always goes into
`postcode`.
the form normalises whitespace, removes extra new lines, and enforces
that you have between three and seven lines.
if the letter repeats address placeholders further down (eg "Dear
((address_line_1))"), then it'll fill those in as well. It'll still
prompt you to fill them in, but they'll be pre-filled.
If someone enters an email address from a domain we don’t recognise we
direct them straight to our support channel. This is causing increased
contact from suppliers and members of the public.
Now that we have a page which explains who can use Notify, let’s direct
people there first. Then if they really do need to contact support
(because we don’t recognise their organisation) then they can do so from
that page.
We have a policy about how suppliers are allowed to use Notify. But we
don’t explain it anywhere. Which drives contact to our support form.
This commit that adds a new page that explains the policy.
I’ve moved the related content about who else can use Notify from the
get started page to this page as well, where it doesn’t need to sit in
a details element.
This is for tickets coming from non-logged-in users. It’s effectively
the same as reporting a problem, but doesn’t have the banner about
the status page (because we can’t tell if they’re actually reporting a
problem now we’re not asking).
It also gives a more generic page title.
We can’t give advice to members of the public, but increasingly we’re
seeing them try to use our support form to ask.
It would be better for them if we can direct them straight to somewhere
more useful, before they have the chance to raise a support ticket.
This commit replaces the report a problem/ask a question triaging for
users who aren’t signed in. It’s not possible for non-signed-in users to
raise an priority 1 ticket, so we never need to triage the tickets in
this way.
Instead we can triage people based on whether they work in the public
sector or not. If they do then we send them on to the feedback form. If
not then they go to a new page which contains some useful links. We’ve
chosen these links based on some analysis of the support tickets we’ve
received recently[1]
1. https://docs.google.com/spreadsheets/d/1uBQn-ZnCYfz6ltFaUKZpytgvBF0-MeshCLZ1cD74R0c/edit?usp=sharing
We are seeing little benefit of allowing users to not put in their email
address. This will mean that you must provide it for feedback, not just
problems with the site.
There could maybe be some more refactoring of the support templates as
this is now very similar to the report a problem page but this is a
quick fix so haven't gone too in depth.
This page is slow to load which means:
- it’s annoying for us
- it’s potentially causing load on the database
This commit does two things to reduce the amount we’re unnecessarily
looking at this page:
1. Avoid redirecting to it when signing in as a platform admin user
2. Don’t go directly to it when clicking ‘platform admin’ at the top,
but instead show a holding page (there’s a fair chance you’ve clicked
that link in order to go and manage some email branding or find a
user, not wait for stats to load)
This test sent an empty string to represent the 'who' field not having a value. This is represented by a group of radios in the page.
In browsers, radios that aren't selected result in that field not being included in the HTTP parameters. This change makes the test match that.
The expected validation message is also changed to the one you see in a browser. Turns out [the WTForms DataRequired validator](https://wtforms.readthedocs.io/en/stable/validators.html#wtforms.validators.DataRequired) produces a different error message for an empty string vs the value being missing ("This field is required." vs "Not a valid choice").
When we first built the contact list feature this endpoint didn’t exist.
Now it does we can remove the slightly cludgy looping-through-all-the-lists
code.
The saved uploads page just shows you the same thing you’ve seen on the
previous page – a list of email addresses.
It’s more useful to see the uploads page, so you can see where the thing
you’ve saved has gone. You can see it more in context.
24px with 19px is what we use on the uploads page. On notifications page
we use 19px with 16px.
There’s some loose idea that the bigger size is for items that contain
other items.
This also increases the line height for recipients of PDF letters to
make things line up.
