A of this commit’s parent we are storing `template_id` and
`original_file_name` in the URL. Getting them from the URL is better,
so the check page no longer needs to look for them in the session. This
commit removes the code that looks for these values in the session.
At the moment you can’t press refresh on the check page if there’s
errors. This is because the session gets cleared when there’s errors.
This is a bad user experience.
The data that this page is relying on (from the session) is:
- template ID
- original file name
Neither of these things need to be in the session because:
- they are not secret
- the user can modify them already (by choosing a different template or
renaming their file locally)
So this commit additionally stores them in the URL.
if a user signs in again, clear their file upload data from any
aborted journeys from before, so that their cookies don't fill up
also add some temporary logging when the session starts getting full.
Because we now[1] store info about each file upload separately in the
session the session isn’t overridden every time you upload a file. This
is good because you can do multiple file uploads idempotently.
Generally we are cleaning up after ourselves because we pop anything to
do with that upload from the session. However there is an edge case: if
you never send the file then the info about the file stays in the
session in perpetuity[2]. This is generally happening when people are
uploading files that are impossible to send, ie ones that have errors.
So this commit makes two changes:
1. remove info about a file upload from the session as soon as we know
that it contains errors
2. `POST` reuploads to the same endpoint as initial uploads because
otherwise we need to keep info about bad uploads in the session,
which would prevent us from doing 1.
1. https://github.com/alphagov/notifications-admin/pull/1968
2. or at least until the session is cleared by the user logging out
Rather than making users contact us to get the agreement, we should just
let them download it, when we know which version to send them.
This commit adds two endpoints:
- one to serve a page which links to the agreement
- one to serve the agreement itself
These pages are not linked to anywhere because the underlying files
don’t exist yet. So I haven’t bothered putting real content on the page
yet either. I imagine the deploy sequence will be:
1. Upload the files to the buckets in each environment
2. Deploy this code through each enviroment, checking the links work
3. Make another PR to start linking to the endpoints added by this
commit
I don’t think it’s a massive risk (we’re certainly mitigating against
any XSS), but having a page on a GOV.UK domain where you can prefill
text on the page from a query string probably isn’t great.
So this commit restricts prefilling the support form to a set of
named questions.
show_accounts_or_dashboard has logic about where you should redirect
to. If we let it do this, then that's nicer than duplicating its
logic. We found that it wasn't accounting for orgs in redirects
properly.
If you have a placeholder called `((phone number))` in your email
template, and you try to send a one-off message then the form input will
attempt to validate your ‘phone number’.
This is not helpful if you’re trying to put a landline number in your
email, for example.
This only affects messages being sent through the one-off interface.
This commit makes the form be aware of template type, which fixes the
problem.
We shouldn’t tell people on one page (the terms page) that we know about
their organisations agreement and then on the pricing page tell them to
contact us to find out what we know about the agreement.
So this commit adds the same logic from the terms page to the pricing
page, with wording that makes sense in the pricing context.
People are emailing us asking if their organisation has signed the
agreement. In some cases they have, so this is a waste of their and
our time.
This commit adds a bit of logic to the terms of use page to tell users
when their organisation has already signed the agreement.
it was only used by the choose service page, and then only in kludgy
ways (eg: creating a list containing one item called "add service"),
so lets rip it out and make this page bespoke. Especially now that it's
changed so much.
if there's a service in the session, go there.
if there's an org in the session, go there.
if the user has one service and no orgs, go there.
if the user has one org and no services, go there.
else go to choose service page
layout as follows
```
ORG_1
SERVICE_1
SERVICE_2
--------------------
ORG_2
--------------------
SERVICE_3
SERVICE_4
--------------------
Add a new service...
```
* org 1 and 2 are organisations that the user has access to.
* Service 1 and 2 are part of org 1, AND the user has access to them.
- There may be more services in org_1 that the user doesn't know
about.
* Service 3 and 4 are services the user has access to.
- They MAY be part of an organisation that the user does not know
about. They can't be part of org_1 or org_2 tho.
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.
This question was designed to make people feel like it was OK to submit
their request without getting the MoU signed. We reckoned that this was
the fastest way of getting their service live (because the MoU is the
bit that’s most likely to slow them down).
We now have a better way of telling people:
- if they’ve signed the MoU already
- or to contact us if they haven’t (which is what the majority of teams
seem to do now)
We were never actually using the answer to this question – we were still
checking for every service whether they had it signed.
So this commit removes this now-redundant question.
The get notifications endpoint needs the template_type for search. The inbox page for inbound sms messages was not passing that through, which caused a 400 response.
This resolves that by passing the template_type to the api.
as it did not need to be called for standard letters.
Changed the tests to use the mock from get_notification_letter_preview
instead of a generic NotificationApiClient.get. This will hopefully
protect any subsequent changes or calls from not being tested in future.
rendering template. Currently it uses the template from the API to
calculate this which for a precompiled template is always 1.
Gets the PDF and then uses the utils method to get the page count.
* Added logic for precompiled letters
* Added test to test the new path
* Updated existing tests now the path has changed
