If there aren’t a range of options (normally presented as radio buttons)
to show the user on the email branding request page then we just show
the textbox. But we were still doing form validation on the radio
buttons, even though the user couldn’t see them to click them. This
stopped the user from being able to submit the form.
This commit fixes the problem by, in this specific case, pre-ticking the
‘Something else’ radio button.
We had been storing whether or not a file was valid in the S3 metadata,
but using the query string of the URL to store the original filename
and the page count. This meant that if you tried to view the preview
letter page without the query string you would see a `500`. It was
possible for this to happen if you were signed out of Notify while on
the preview page - you would be redirected back to the preview page but
without the query string, causing an error.
Updating an organisation’s branding might now also update the branding
of services associated to that organisation. This is similar to how
updating an organisation’s type can update the organisation type for its
services.
In the latter case we already make sure to clear the cached version of
these services which is held in Redis.
This commit does the same clearing of the caches when updating an
organisation’s branding (and does a bit of refactoring to do so without
duplication of code.)
Letting people input a bit of free text should reduce the amount of back
and forth we have to do over support tickets when setting up someone’s
branding.
If something else is the only option then we don’t show the radio button
at all and have just the free text input on the page (not behind a
progressive disclosure).
Users who work in local government can’t have GOV.UK branding on their
emails. And only those working for Companies House (for example) can
request the Companies House branding.
This commit adds:
- new choices of email branding, which offer the name of the branding,
rather than the style
- logic to filter this list to only the applicable options, based on
what we know about the user, service and organisation
This is a change from the previous approach which put the onus on users
to figure out the style of branding they wanted, when we might already
know that a lot of the options weren’t available to them, or would be
inconsistent with the branding of other services in their organisation.
Added a send button which only appears on the page if the query string
indicates that the PDF is valid. Before actually sending, we check that
the service has the right permissions and that the metadata for the
letter confirms the letter is valid (because the query string can be
changed).
This sanitises uploaded letters and stores the sanitised result in S3
with if it passes validation or the original PDF in S3 if validation
fails. A metadata value of 'status' is set to either 'valid' or
'invalid'.
This checks that the PDF file is not malformed in some way (e.g. by
missing the EOF marker). We check this by trying to get the page count
of the letter which will be needed to display the preview of the letter.
Added a form to upload a single letter. Currently this only uses the
form to validate that a file is submitted and that the file is a PDF. If
either of these validations fail, the form will display an error.
Otherwise, we redirect to a new preview page which just has the filename
as the heading for now.
All we do via support is ask which organisation they work for and
manually assign their service to it. This commit makes that process self
service.
We think we have all the trusts and clinical commissioning groups
loaded into the database now.
This will make the go live process smoother for these teams.
Most GP practice services are named after the practice, which is the
organisation.
So rather than make people re-type the name of their organisation (and
potentially make a typo) let’s just let them say ‘yes, that’s the name
of my organisation’.
We have a bunch of GP surgeries who want to go live. They don’t
automatically assigned to organisations. So this means a lot of back and
forth to get these organisations set up, and then the service has to
re-request to go live, and… it’s painful.
Instead, let’s let GPs create their own organisations, by confirming the
name of their organisation before going on to letting them accept the
agreement.
We want GPs to be able to accept the agreement online. But at the moment
they don’t get automatically assigned to organisations. So we need to
let them enter the agreement accepting journey even if they don’t have
an organisation set up.
Although their allowances are the same as what we call `nhs_local` it
makes more sense to store them separately because:
- we already present them as two separate choices to the user
- we may want to handle them differently in the future, eg in terms of
what branding choices are available to them
Once the API is updated we can start passing in this new value from
the admin app.
We’re defining the list of org types in a few different places. This
makes it more likely we’ll forget to update one of these places, thereby
introducing a bug.
This commit moves the definition to be on the organisation model, which
feels like a sensible enough place for it.
The uploads hub is just a page with text for now - there are no actions
available on the page. It is linked to from a new 'Uploads' menu item on
the left of the page which is only visible if your service has the
`letter` and `upload_letters` permissions and if the current user has
permissions to send messages.
We added `Upload letters` to the platform admin service settings, which makes is confusing when next to `Upload documents`.
Also `User auth type editting` is a confusing label
`User auth type editting` --> `Email authentication`
`Uploading documents` --> `Send file by email`
The upload_letters permission can only be changed by Platform Admin
users. It works in a similar way to the inbound_sms nested permission
- you only see the row in the table if you have the 'letter' permission,
but the 'letter' and 'upload_letters' are still separate permissions and
changing one does not affect the other.
