It’s useful to get some kind of preview of the report before you
download it.
And if there’s only a few letters in there then you might not even need
to download it at all.
For teams with lots of letters we don’t want the page to load too slowly
so let’s cap the number of displayed items to 50, same as previewing
a spreadsheet.
This follows our pattern for other downloadable reports, and gives
people who know/care about stuff like file types some indication of what
they’re about to download.
This page displays a list of available reports, a report is a set of returned lettters that have been reported on the same day.
Each line of the page is a link that can download the report.
I'm not sure the format of the csv is right. The data might be confusing especially if the service has a mix of precompiled templates and jobs.
Units tests are still to come.
Users who have an API integration (and therefore have a way of passing
in a reference for each notification) can now search by that reference
(see https://github.com/alphagov/notifications-api/pull/2682)
This commit changes the label on the search box to tell these users that
this is possible, without changing the label for users without an API
integration, who might get confused by what ‘reference’ means.
It also makes the label consistently say ‘email address or phone number’
(ie email address is first) because this is our content style.
Makes these assumptions:
- we don’t care about history before 29th November 2019 at 11am (this
is when priority started to mean a proportion rather than a ranking)
- the priority of the second provider will always be the inverse of
the first provider
Which means the code is a lot simpler/actually does what you’d expect.
Their priority should always add up to 100%. Currently we have to ensure
this by hand. Adding this form means there’s no way to not set their
combined priorities to 100%. And it’s a bit more of an intuitive UI than
two textboxes on separate pages.
It’s not very useful to know the priority of one provider without
knowing the other. And these pages were never really designed, so they
weren’t super easy to understand anyway.
This commit adds a page that takes the first two text message providers
and shows their relative priority against each other.
It follows the design of the events page, as a pattern for showing a
log of historical events.
New units tests have not been written for this page because it is very like this will be refactor and probably a new template created for the page. Some design needs to go into this page.
But we needed something ready for user research.
we have a hunch that some session related issues that we've seen over
the last few weeks might be related to weird race conditions where
cookies set by subresources (image previews of letters on the send flow)
arrive just as the img request is cancelled because the user has clicked
on a button to navigate to a new page, but still manage to set the
cookie? We're not entirely sure what's going on, but we've got a hunch
that not setting cookies on image fetches sounds sensible. Images are
always loaded as a subresource (ie: through a `src` tag in an html
element), so they should never need to change the cookies, so this seems
sensible. We've done this by creating a new blueprint that doesn't set
session.permanent, and doesn't call `save_serivce_or_org_after_request`
either.
cookies are sent back to the browser if:
`sesion.modified or (session.permanent and 'REFRESH_EVERY_REQUEST')`
(where the latter is a config setting).
Turning off REFRESH_EVERY_REQUEST (which is True by default) means that
we will only update the sesion if it's been modified. In practice,
literally every request is modified in the after_request handler
`save_service_or_org_after_request`. This is accidentally convenient,
as it guarantees that we'll still send back the cookie normally even
though refresh_every_request is disabled. Sending back the cookie
updates the expiry time (20 hours), so we need to keep doing this to
preserve existing session timeout behaviour.
Re-upload button is only shown if file failed validation.
Change wording of re-upload buttons
Make test we test right buttons on letter upload preview page
Also remove double backlink
We can use the ‘Uploads’ feature to check if letters are printable now.
This code works in a completely different way, so if we kept it we’d
have to maintain two different code paths, and make sure that they
didn’t diverge.
Also deletes the related HTML templates.
Since we’re only showing this page to team who are using the API we
don’t have to worry about explaining what’s going on in terms of the
spreadsheet any more.
This makes the page simpler.
We introduced the ‘breaking change’ page[1] partly to help teach people
about the relationship between the placeholders in their template and
the data they were providing. Data can be provided either by API or by
uploading a spreadsheet. The users who we struggled to communicate this
relationship to were the ones using the upload a spreadsheet feature.
We made two changes to the context of this feature:
1. Around the same time we introduced the interactive tour[2], which
ultimately proved to be the thing that helped people understand the
relationship between the data they were providing and the
placeholders in the template.
2. We introduced a way for people to send one-off messages without
using the API or uploading a spreadsheet[3]. So for this page to say
that you’ll need to update a spreadsheet or change an API call if you
change the placeholders in your template is no longer accurate.
Therefore I think it makes sense to only show this page to teams who are
using the API to send messages. The best proxy we have for that is to
look at whether they’ve created any API keys.
***
1. https://github.com/alphagov/notifications-admin/pull/631
2. https://github.com/alphagov/notifications-admin/pull/613
3. https://github.com/alphagov/notifications-admin/pull/1293
Requests to go live and email branding requests come through to Zendesk
with tags attached automatically.
With the revised taxonomy some of these tags need to be updated, as
summarised in this spreadsheet.
In addition, `notify_action` tag has to be added in each of those cases.
Old|New
---|---
`notify_request_to_go_live_complete`|`notify_go_live_complete`
`notify_request_to_go_live_incomplete`|`notify_go_live_incomplete`
`notify_action_add_branding`|`notify_branding`
`notify_request_to_go_live_incomplete_mou`|`notify_go_live_incomplete_mou`
`notify_request_to_go_live`|`notify_go_live`
– https://docs.google.com/spreadsheets/d/1o5ATsFsVK8Qpj7x8QvxX-SfEuBZ75028GEySVcdBFYU/edit#gid=0
– https://www.pivotaltracker.com/story/show/169842970
Flask will pick the first route that matches. Decorators get applied
from innermost to outermost.
So if the same endpoint is served at `/abc` and `/123` the one used
when `url_for` is generating a URL is whichever decorator is lowest
(in terms of line number).
It doesn’t functionally make a difference, but it’s causing the
functional tests to fail at the moment. And shorter URLs are nicer, so
I think it makes sense to change here, rather than change the tests.
`all` is not a real template type, so for links to template folders that
apply to all template types we have a URL that looks like:
```
/services/<uuid:service_id>/templates
```
However Flask only generates this url when `url_for` is called with
`template_type=None`. If called with `template_type=all` then Flask will
generate a URL like
```
/services/<uuid:service_id>/templates/all
```
However attempting to load this URL will now 404, since `all` is not a
template type recognised by the regex introduced in
https://github.com/alphagov/notifications-admin/pull/3176
It would be nice to not have URLs with `all` in them at all, but since
people might have bookmarked them we need to support them indefinitely.
Also considered but decided against adding `all` to the set of template
types because it might cause other problems, for example attempting to
create a new template with a type of `all` would never work.
`all` is not a real template type, so for links to template folders that
apply to all template types we have a URL that looks like:
```
/services/<uuid:service_id>/templates/folders/<uuid:template_folder_id>
```
However Flask only generates this url when `url_for` is called with
`template_type=None`. If called with `template_type=all` then Flask will
generate a URL like
```
/services/<uuid:service_id>/templates/all/folders/<uuid:template_folder_id>
```
However attempting to load this URL will now 404, since `all` is not a
template type recognised by the regex introduced in
https://github.com/alphagov/notifications-admin/pull/3176
It would be nice to not have URLs with `all` in them at all, but since
people might have bookmarked them we need to support them indefinitely.
Also considered but decided against adding `all` to the set of template
types because it might cause other problems, for example attempting to
create a new template with a type of `all` would never work.
The recipient of the letter now displays at the bottom of the page when
previewing a valid letter. The template preview `/precompiled/sanitise`
endpoint returns the address, but we format it to display on a single
line with commas between each line. We also need to convert the
recipient address to ASCII so that it can be stored as S3 metadata.
The `action_blocked` endpoint needed a variation of the URL without
a `template_id` parameter, because `None` is no longer a valid
`template_id` (because it’s not a UUID).
This change was made in 265931d21746918c4ddfc19c4ad3f8cb5683c1bf, which
also removed the `return_to` parameter, because the back link on the
`action blocked` page only ever goes to `add_new_template` if there’s
no `template_id` provided.
However this was conflating the two things, so I’ve wound it back a bit
so that:
- there’s still a new route, whose URL doesn’t include `template_id`
as a parameter
- `return_to` is always required
I’ve also refactored the code a bit to move the looking up of the back
link from the Jinja into the view layer, so that the related code is in
one place and easier to reason about.
Sometimes we manually check that a URL parameter is in a required set.
Sometimes we don’t bother.
This commit adds a URL converter to do this so that:
- we don’t have to re-write the same code every time
- it’s easier to apply this check to other endpoints
This means endpoints that previously allowed a `template_type` or
`message_type` of `None` now 404. So I’ve had to add new routes for
with URLs that don’t include such parameters.
So this…:
```
/services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv
/services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/None.csv
```
…becomes:
```
/services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications/sms.csv
/services/128b91b6-2996-4107-bb65-51b7c24a728d/notifications.csv
```
This matches what we do for the HTML-responding equivalent (see
265931d217/app/main/views/jobs.py (L215-L216))
We mostly rely on the API returning a 404 to generate 404s for trying
to get things with non-UUID IDs. This is fine, except our tests often
mock these API calls. So it could look like everything is working fine,
except the thing your passing in might never be a valid UUID, and thus
would 404 in a non-test environment.
So this commit:
1. uses the `uuid` URL converter everywhere there’s something that looks
like an ID in a URL parameter
2. adds a test which automates checking for 1.
Because it means you often have to cast to string in your application
code just to get your tests passing.
The method being monkey patched is originally defined here: b81aa0f18c/src/werkzeug/routing.py (L1272)
Show valdiation failed messages on letter notifications in red text,
not in the banner like we do on Uploads and Validation checker pages.
This is because it is a different step in the journey: the user
has already sent the notification and styling needs to be in line
with other places where user is checking the notification she already
has sent.
