`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.
This reverts 1b1839ad30, which removed
the usage from the dashboard because it was causing performance
problems:
> **The yearly usage section on the dashboard page takes too log as a
> result services with large yearly stats are timing out.**
>
> As a short term fix we have taken the yearly stats off the dashboard.
>
> There is a plan to create permanent statistic tables to warehouse the
> data.
The long term fix (the fact tables) is now in place, so it should be OK
to bring this back.
This is part of a wider piece of work to refresh the dashboard page now
that jobs are moving to their own page.
Decided it was better to call this then not. This does rely on
the file_id not being corrupted so the file_id passed
into `uploaded_letter_preview` is valid but am taking that risk
given it should only change if a user is changing the form html.
Adds ability to have inline radio buttons using the fieldset.inline
functionality from gov.uk elements.
Then implements this for the radio buttons for choosing postage
class.
Also overrides the gov uk elements styling for the inline radio
buttons to place them slightly closer together as this looks
better.
Flake8 Bugbear checks for some extra things that aren’t code style
errors, but are likely to introduce bugs or unexpected behaviour. A
good example is having mutable default function arguments, which get
shared between every call to the function and therefore mutating a value
in one place can unexpectedly cause it to change in another.
This commit enables all the extra warnings provided by Flake8 Bugbear,
except for the line length one (because we already lint for that
separately).
It disables:
- _B003: Assigning to os.environ_ because I don’t really understand this
- _B306: BaseException.message is removed in Python 3_ because I think
our exceptions have a custom structure that means the `.message`
attribute is still present
HighlightTags was bad because:
- we haven’t called placeholders ‘tags’ for a long time
- it also does resizing of the `<textarea>`, not just highlighting the
placeholders
Scrolling within textareas on the page is a bit grim. Which is why we
don’t do it for the textboxes that people use to edit templates.
This commit will allow us to extend the auto-resizing of `<textarea>`s
to those which don’t need the highlighting of placeholders.
The code is still quite coupled to the placeholder highlighting code,
because both work by copying the content of the `<textarea>` into a
`<div>` that underlaps the textbox. This `<div>` is used for both
rendering the placeholder highlights, and calculating the natural height
of the content. So it would be hard/confusing to split the two bits of
code into separate modules.
If you’ve only used one template then this section of the page isn’t
doing its job, which is to show a comparison of the different kinds of
message you’re showing.
I think our initial assumption was that everyone would be using multiple
templates, so it was good to show this part of the page during the
onboarding, to show users where the information was going to appear.
But we have lots of services who only send one template now, typically
where they’re populating the contents of the template themselves. In
which case this part of the page doesn’t offer them any value.
We hid letters originally because it wasn’t a mature feature. We rolled
it out by letting teams choose to use it (#1803)
and then automatically giving it to new teams (notifications-api/#1600).
This commit doesn’t change who has access to letters, but it does make
it more discoverable by revealing it in the UI. This is the same thing we do for emails/texts, where even if you switch them off they still show up on the dashboard and usage
page.
The mixture of three column/two column layouts on this page has always
looked a bit disjointed. And since the left column will only even
contain the names of months, which are short, it doesn’t need a full
half of the page width.
Even if your service doesn’t send letters now, it might have done
previously.
The original reason for hiding letters was because it wasn’t a mature
feature. But now that it is, we should make it discoverable even for
existing teams. So that means not conditionally hiding it.
This is the same thing we do for emails/texts, where even if you switch
them off they still show up on the dashboard and usage page.
At the moment they can only see it if there are existing jobs. This
commit lets them also see it if their service can upload letters,
because caseworkers might be the ones uploading some letters.
