The previous, manual calculation could be incorrect depending on
which SMS rates the free allowance was attributed to.
The new field also supersedes the old "letter_total" bolt-on so we
can get cost information consistently for both types.
This adds missing assertions for email and SMS usage, as well as
letters with the help of some additional test data.
Previously we were only checking monthly usage (in other tests).
The "with_letters" was mostly a duplicate of the one before - no
change in test setup - bar the three assertions at the end.
Having the assertions in a separate test will help keep the one
above manageable as we add more assertions for the annual usage.
This will make the following changes clearer.
In the next commits we'll go into more detail about "billing_units"
and how it differs for SMS vs. emails and letters.
At the moment, we put the sms rate on the usage page for each
months billing data by taking the single sms rate for the year.
The assumption that there will be a single sms rate for the year is
no longer going to be true. Therefore, instead we take the sms
rate from the monthly data itself which tells us the rate for
a months worth of sent SMS.
This will allow both prometheis (the shared one and our own) to scrape
the /metrics endpoint, each with their own authentication
See alphagov/gds_metrics_python#1 for more details
This required bumping the minimum version of boto3 with:
pip-compile -P awscli requirements.in
I haven't looked into the awscli/boto3/botocore changes due to the
high churn on those libraries. Given they're minor changes we can
assume they are benign. s3transfer changes are also benign [^1]
[^1]: https://github.com/boto/s3transfer/blob/develop/CHANGELOG.rst
make it consistent - always use a + to concatenate strings, always have
that + at the end of the line.
(also remove a rogue "when" from some test names)
the safe filter is quite dangerous - it allows HTML to be rendered as
passed through (the default action is to escape all html), so should
only be used with trusted input. Move it so we only apply it to fields
we specifically expect to have HTML in - in this case, some tables
contain links to other pages.
Also, clean up the variable names for some of these info tables, as they
didn't really make sense.
Previously it was hard to distinguish ids from identifiers from
display names (in the case of the email fixtures).
Using predictable attributes will also make it easier to convert
this dictionaries to proper fixtures.
