Telling users that they can’t send to more than 50 recipients in trial
mode doesn’t apply for letters (they can’t send to _any_ recipients).
So we should make sure that the error message about not being able to
send to any recipients always comes up instead of the 50 recipients one,
whether you’re trying to upload a file with 1 or 111 rows.
Users in trial mode haven’t signed the MOU. This means that they haven’t
agreed to pay for any costs they incur.
Unlike text messages and emails, we don’t give you any free allowance of
letters. Sending _any_ letters will cost the user money.
Therefore we shouldn’t let users who haven’t agreed that they will pay
for the service to incur costs by sending letters.
The pattern used for this is roughly the same as other trial mode errors
that we have already, ie a red box that says you’re not allowed. Not
sure if this is exactly right because it’s not exactly an error so the
pattern might feel too heavy-handed.
Getting this in place means we can turn letters on for users in trial
mode without worrying that they’ll accidentally send real letters, which
would result in:
- us having to absorb those costs
- some awkward conversations
Turns out the counts were all showing as zero because the generator had
already been consumed by the time we were trying to do the stats. Making
it a list comprehension means it can’t get exhausted.
This was causing a 500 in production.
This commit:
- reverts the code the working state it was before 68a1426e58
- figures out a way to make the tests pass without breaking the actual
app
- confirms that mocking things is hard
I don’t think it adds anything to tell you that a key’s never been used.
The value of the ‘key was used 3 minutes ago’ message is in stopping you
accidentally revoking something you shouldn’t have.
This makes errors on all pages have a `<h1>` element, which is important
for accessibility. It means a bit of rewriting the messages, but I think
they’re better for it.
Currently revoking an API key takes you to a separate page. It should
work the same way as other destructive actions, ie staying on the same
page but with a banner asking you to confirm the action.
Looks like `radio_button.text` no longer works. Probably a BeautifulSoup
change. More robust to look at the text of the label and the value of
the input anyway.
We have two new pages for live and trial services that:
- are faster loading
- are now linked to
So the list of services doesn’t need to be on the platform admin index
page any more.
We have a lot of services now. Mostly we want to look at what live
services are doing. So loading up the trial mode services every time
slows things – generating, rendering and using the page – right down.
This commit adds two new pages, one to view only live services, and one
to view trial mode services.
When I split up the error messages on the check CSV page into multiple
templates, I also reduced the repetition of wrapping `<div>`s and macro
calls by moving them up outside the conditional blocks (see
8e947f315d).
Unfortunately I didn’t make the same adjustments for the one-off flow,
which meant that errors on these pages lost their styling. This commit
re-adds the styling for these error messages.
This was causing a 500 because of a bug in utils. It only occurred when
there was missing data for a cell in the recipient column. I’ve also
added a test for missing data in a non-recipient column just in case.
Adds a new endpoint that works like view template/view preview of
letter, so that this page works the same way it does for emails/text
messages (ie showing the full content of the message, including
personalisation).
We’re not worrying about redaction in letters for now.
The status won’t ever change from sending for letters. For now at least.
And even when we do come up with more useful statuses I’m not convinced
it’s useful to expose them to our admin users.
A more useful piece of information to show is when we think the letter
will be delivered.
There’s no immediate feedback with letter jobs, unlike email or text
messages jobs where you see the numbers starting to tick over straight
away.
We need to reassure the user that the thing they asked us to do (send
letters) is underway. ‘Printing’ feels like the natural first state of
the letter-making process. So this commit adds a banner to tell the
user that printing is the thing that’s happening.
The sending/failed/delivered thing:
- doesn’t map to the actual states of letters
- doesn’t respond quickly enough to give you feedback that something is
happening (because "sending" doesn’t even go to "probably delivered"
for a few days)
This commit replaces these 4 boxes with some more useful information:
- one number – how many letters were in the job in total
- when we estimate that the letters will be delivered
The status for each letter in a job will be the same for every single
letter (at least until we start dealing with returns).
It’s redundant to show this information over and over again. This commit
removes it.
The idea is if you decide your problem isn’t such an emergency after
all, we direct you to the form where you can report it as such. This
link wasn’t working because it didn’t understand `False` to mean ‘not
severe’. Only ‘no’ means not severe.
The result was that users got sent in a bit of a convoluted loop
where they were asked again if their problem was an emergency or not.
Testing this by making sure that both:
- the URL in the link is what we expected
- when visited it gives the page title we expect
Because even if we had had the first test only, it wouldn’t have caught
this bug.
We changed the schema used by the endpoint that searches for
notifications by recipient. So the admin app was looking for the wrong
thing in the JSON.
This is hard to catch in tests because it relies on our fixtures
matching what the API really returns.
This commit fixes the code to use the correct key to lookup the template
content from the JSON.
This also exposed the fact that we weren’t passing in the
personalisation any more (perhaps got lost in the re-reverts somehow)
so users were only seeing the template in the inbound view, not the
full message content.
If sending SMS is disabled for a service, it should not be possible to
add or modify SMS templates. If a user tries to do this, they should see
a different page with a link to go back. The same thing should happen
with email templates.
Platform admins can now disable sending sms for a service. If sending
sms is disabled, this will also hide all the other sms options in the
Settings table.
Platform admins can now disable sending of emails for a service. If
sending emails is disabled, this will also hide the option to change the
Email reply to address.
`test_utils.py` is actually a file for testing some utils, not
some utils for testing.
Test helper functions and fixtures are better placed in conftest,
and also means that we can use them in conftest.
