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)
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.
On the uploads page this should be newest first, same as the scheduled
and immediate jobs on this page.
On the _choose_ page this should be alphabetical, same as choosing a
template.
Uploads page is where all the stuff you’ve uploaded lives. Now you can
upload contact lists they should live here too.
They always come first because they’re the most-removed from stuff
you’ve sent.
Since contact lists only store the email address or phone number, this
won’t work. So we should warn people, and highlight that the
personalisation in the template is the problem, since this is what they
will need to change.
You can’t send an email message template to a list of phone numbers. So
we shouldn’t show you the lists of phone numbers when you’ve chosen an
email template.
You’ll be able to use a contact list by first choosing a template, then
choosing the list you want to use.
At the moment this shows all lists, not just the ones that are
compatible with your template.
In order to use a contact list we’re going to put you in the normal
upload a spreadsheet journey. Except without having to upload again.
So this commit adds an endpoint that takes the file from the contact
list bucket, puts it in the same place it would have gone if you’d
uploaded it, then sends you on your way.
We don’t want to muddy them up with the normal CSV uploads.
I’ve tried to reuse the existing S3 code where possible because it’s
well tested.
Buckets have already been created.
We increasingly have teams wanting to do business-continuity type
messaging. They might be without access to their normal systems, which
is where they would otherwise go to get the list of email addresses or
phone numbers.
So we want to give them a place in Notify where they can store their
spreadsheets and use them at a later date.
For the initial pass we’re going to scope this to only allowing
spreadsheets with one column, ie just phone numbers/email addresses.
This is because:
- it minimises the amount of personal info we’re storing
- it reduces the chance of getting a placeholder error when you go to
send the message, which is probably a high-stress situation where you
might not be able to re-generate the file
The code for this is mostly copied from the existing upload CSV journey.
It’s quite duplicative, but that’s what I needed to do to get this out
quickly. There are opportunities for refactoring later.
Similarly, I would have liked to split this up into better commit
messages, but it really was a case of just bashing code out until it
worked 😳
This commit does not:
- implement the ‘view a contact list page’ (it just has a placeholder
because the API isn’t ready at the moment)
- link to this page (because it’s not ready to use yet)
We’ve done this already for services with the upload letters permission.
And all services can upload letters now.
But we’re still returning it in the JSON response we use to AJAX-ify the
page.
Since the jobs response can query stats for up to 50 jobs at a time this
puts some load on the API/database. Hopefully this might drop that load
a bit.
There was a bug that displayed the error message with 2 red error boxes around the error message.
Also need another else to handle a new error message from the API, the old one can be removed after the API is deployed. But this can go first. I tested this branch with API master and the API branch with the change. I tested one off SMS and a CSV upload.
The uploads and jobs page should start showing in the _Uploads_ menu on
the left hand side.
If you’ve navigated to a job from the uploads page (ie you haven’t got
to that page because you’ve just sent the job) then you should see a
link back to the uploads page.
The postage covers up some of the letter, so it can hide the problem. It
also implies that the letter has been put in an envelope, which will
never happen if it fails validation.
This matches what we do for uploaded letters.
