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 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.
We have a `client_request` fixture which does a bunch of useful stuff
like:
- checking the status code of the response
- returning a `BeautifulSoup` object
Lots of our tests still use an older fixture called `client`. This is
not as good because it:
- returns a raw `Response` object
- doesn’t do the additional checks
- means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')`
This commit converts all the tests which had a `client.login(…)`
statement to use `client_request` (which is already logged in by
default).
Subsequent commits will remove uses of `client` in other tests, but
doing it this way means the work can be broken up into more manageable
chunks.
We chunk history entries by their YYYY-MM-DD date representation to
display them day-by-day.
However trying to convert a YYYY-MM-DD string into a timestamp is
unpredictable, and was causing our dates to be one day out (probably
because of midnight/daylight savings/general datetime horrors).
This commit changes the code to do the same thing as the history page,
which is look at the `updated_at` field on the first entry to get a
datetime object and from that the formatted date we show in the headings
on the page.
Makes these assumptions:
- we don’t care about history before 29th November 2019 at 11am (this
is when priority started to mean a proportion rather than a ranking)
- the priority of the second provider will always be the inverse of
the first provider
Which means the code is a lot simpler/actually does what you’d expect.
We mostly rely on the API returning a 404 to generate 404s for trying
to get things with non-UUID IDs. This is fine, except our tests often
mock these API calls. So it could look like everything is working fine,
except the thing your passing in might never be a valid UUID, and thus
would 404 in a non-test environment.
So this commit:
1. uses the `uuid` URL converter everywhere there’s something that looks
like an ID in a URL parameter
2. adds a test which automates checking for 1.
- API will now send through `created_by_name` instead of `created_by`.
- API will always send through `current_month_billable_sms` but this can
now be `0` instead of `None`.
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
