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.
This makes the rendering the same as for "created_by_name" when the
data isn't present. It's a bit more complicated for "updated_at" so
I checked that it's implicitly covered by the tests, which fail if I
remove the "if" conditional for any of these fields.
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.
The prometheus-client was pinned to avoid installing version 0.10.0,
which removed support for `prometheus_multiproc_dir` and renamed the
variable `PROMETHEUS_MULTIPROC_DIR`. Version 0.10.1 reintroduced support
for the lowercase `prometheus_multiproc_dir` environment variable.
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.
Using "primary" made sense when the other "secondary" provider was
new, but today we see them as equivalent and the terminology is a
bit confusing. In future we may add a third provider as well.
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 decided to use NVM to manage installed Node versions locally
and in CI to ensure they match and produce consistent builds.
Running `nvm install` will install the Node version specified in the
`.nvmrc` file.
This is now consistent with Document Download Frontend.
See: alphagov/document-download-frontend#114
Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
Creates a "v2" package-lock.json file for consistent dependency
installation.
Lock file created using `npm i --package-lock-only`
Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
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.