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.
Previously we used AWS which meant that we could create wheels
from our requirements and then install them offline which made
deployments quicker.
We're no longer using AWS so let's remove that.
Although CloudFoundry supports installing dependencies in an offline
environment as documented here:
http://docs.cloudfoundry.org/buildpacks/python/#vendoring
To achieve this we create a vendor/ directory which will contain
the packages to install. This uses --no-index and --find-links so will
not resolve for any dependencies from pypi. For this reason there is
assumed confidence that the vendor/ directory will contain all
of the dependencies we need.
Google analytics lets you send:
- pageviews
- events
Page views are used by default. But sometimes you wanna count something
which isn’t the user navigating to a new page, or you wanna track
something which isn’t just what page they were looking it. This is where
events are useful.
This commit adds a small JS module that lets us fire off an event when
the presence of an element with the right data attributes are present on
the page.
The reason to indent the first column heading is so that the number 1
lines up with the numbers of subsequent rows.
This only happens when the subsequent rows are indented because of the
red bars. This is only when there are row errors, not when there are
more general errors.
There was a lot of repetetive wrapping code being repeated for every
conditional block in these files. Let’s wrap it around the whole
conditional bit once instead.
If you have errors in your file then there’s stuff you’re not going to
see on the page. So this doesn’t need to be in the Jinja templates that
are only used when there are errors.
Basically the conditional stuff is moving up to the level above these
templates.
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.
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.
It will also be useful to know (especially for the API):
- when a letter was printed
- if it’s been printed or not
This commit:
- adds code to calculate these two pieces of information
- refactors the function to return a `namedtuple` – a tuple of two items
was manageable, but with four items it was getting hard to know what
each one meant – this lets us label each piece of information that is
being returned
Letter delivery depends on:
- how long it takes to print
- how long it takes to post
Both of these process are impacted by weekends, because people don’t
work on weekends.
It also depends on if you submit your letter before or after 5pm,
because that’s the cut off time for getting a letter printed on a given
day – ie after 5pm on Monday is effectively the same as Tuesday and so
on.
But I reckon all our users need to know is roughly how long it will take
until the letter turns up on the user’s doorstep. So this commit adds
a function to calculate this. Doesn’t surface it on the front end _yet_.
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.
