This is slightly less efficient than getting the folder dicts from
"get_user_template_folders" directly, since:
- TemplateList returns both templates and folders.
- TemplateList encapsulates the dicts in model classes.
We'll compensate for this later on:
- We'll introduce a new caching approach to make the call fast.
- We'll expose a property to avoid the "if" in the comprehension.
Part of moving "get_template_folders" et al. into TemplateList so we
can cache it more effectively. This is slightly less efficient as
iterating a TemplateList will instantiate an object for each item
in the folder; but the difference is minimal.
Note that:
- The default template_type for TemplateList is "all".
- We need to pass realistic template "JSON" in the test now.
The only impactful change is the major version itself, where I've
fixed the breaking changes due to the upgrade of PyPDF2 [^1] and
checked there are no deprecation warnings when I run the tests.
[^1]: https://github.com/alphagov/notifications-utils/pull/973
Similar to the bug shown here
https://www.pivotaltracker.com/story/show/181513431, but to fix the case
when previewing a letter send using a CSV upload it wasn't using
template values to calculate the page length.
This did more than it said and had some unconventional behaviour:
- It modified the input data. We can avoid this by computing the
postage group on-the-fly and using "sorted" instead of "sort".
- It defined a custom, named tuple. This isn't necessary as Jinja
allows us to access elements by qualification (".") already.
We can also use the same lambda function to group and sort items,
since the sort predicate is the same one we use to group them.
This starts using the sms_{cost, charged, free_allowance_used}
fields in the new API to replace the "get_free_paid_breakdown"
function we had before, which could not support multiple rates.
In order to use "get_free_paid_breakdown" the calling method had
to store a "cumulative" variable to calculate the free allowance
used so far, which is now done by the API.
To calculate the data for conftest.py, I had to start from the
bottom ("April") and manually calculate the free allowance used
to emulate the API - this is what "cumulative" used to do.
This is also an opportunity to DRY-up the filtering of usage by
month, which we will reuse in the following commits. Doing a sum
is simple enough that it can be done inline, avoiding indirection.
So we don’t have to deploy a change on a Saturday.
In the future this could pull from the rates in the database, but while
that code is shifting around I didn’t want to touoch it. We’d also have
to think about caching so as not to have a non-authenticated route
hitting the database.
Note: I've removed the pricing assertion in the "0_free_allowance"
test as it's covered elsewhere - the value of the test is really to
check that we don't show the remainder if there never was any.
Ryan Ahearn