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.
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.
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.
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)
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.
We could alternatively put the "add up to 100%" error on the page
using form-level errors [^1] and a custom flash message. Putting
the error on each field is slightly simpler and does make it clear
the issue is with all of the fields together.
[^1]: 22636b55ed
This replaces the slider with an integer input for each provider.
Unfortunately showing a variable number of inputs isn't easy to
achieve in WTForms [^1], but we think this is the least worst way
to do it vs e.g. not using WTForms at all.
[^1]: https://github.com/wtforms/wtforms/issues/736
This isn't used and showing priorities when we only have a single
provider or where they have no effect is unnecessarily confusing.
Removing the form makes it clearer that there's only one way to
adjust priorities for domestic SMS providers.
If we add another email or international SMS provider in future,
we would need to rewrite the form here anyway as the priorities
need to be adjusted in tandem, not individually.
This results in some new errors from flake8-bugbear:
```
B020: Loop control variable overrides iterable it iterates
```
I can't see an issue with the places that we do this, so have ignored
these warnings. If we keep getting these and they look fine, we can
create a global rule to ignore B020.
This fixes a bug where a third inactive provider would (potentially)
appear in place of one of the two active ones, depending on the order
of its identifier compared to the other two.
In future we may look at simplifying this to cope with more than two
active providers. For now, the existing UI will continue to work when
we add a new, inactive SMS provider for Reach.
Previously I found it hard to audit these tests when they flipped
between emails and letters when scrolling vertically.
While these have much in common, they are still separate features
and will evolve separately.
This is now covered by the unit tests for the new branding module.
Showing the "something else" text box is also already covered by
another UI test, so we don't need it for that either.
