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.
I’m hoping that if I can design something that clearly differentiates
them then we won’t need to do so by putting them in separate tables,
which then need labelling, which would clutter up the page.
The logic around what gets shown on the uploads page was hard to follow.
This commit makes three changes to hopefully make it easier:
- remove the passing-around of a string containing the contents of a
rendered partial
- encapsulate everything in one `show_scheduled_jobs` variable, rather
than mixing between `scheduled_jobs` and
`current_service.scheduled_jobs`
- adds a comment to explain why we still render `_jobs.html` even when
we know we have no jobs
