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.
This is possible now we're testing letters and emails separately.
I've added a few missing cases for NHS and non-central branding.
In the next commits we'll look at the remaining special cases.
These all behave the same as each other so there's little value in
testing all of them - if we had 100 org types we wouldn't test them
all, but it's easy to get carried away when there are fewer.
We already had different functionality for email branding and will
soon be adding more for email branding pools.
Note that the "get_available_choices" class method was only used for
email branding - we can do it in the constructor for letters.
Users who have no mobile number set, users who are not on email auth
and users who are not on "Change mobile number" page should not
see the delete link.
This made it easier to debug a problem with the functional tests
due to the fixtures not working correctly [^1]. It's a platform
admin only convenience over knowing the page URL.
We may want to expose the top-level "/api-integration" page but
that will require more work to show which broadcasts were sent with
which key - currently it's oriented around "messages". For now I
think it's useful to see what keys a service has.
[^1]: https://github.com/alphagov/notifications-functional-tests/pull/411#pullrequestreview-920069799
We added this for the 25 May demo. We’re unlikely to need it again.
We’re also unlikely to need this library again, so this commit removes
the source and the code that creates it.
Central orgs have more options than others, including the option
to revert back to GOV.UK once branding is set. Combining the tests
together should make that a bit clearer.
All of the mock / UI assertions in these tests are covered by the
tests above them - these tests were mostly targetting which options
were being shown, which we can check at a lower level.
This is much simpler than trying to test the function via the page,
although there are still two scenarios to test there:
- The page with radio buttons (using NHS as an example).
- The page with a text form (using "other" as an example).
In future work we could split this test in two to make it clearer
what it's trying to test. For now, this keeps the diff simple.
On the ‘find user’ page it says ‘sms_auth’ instead of ‘Text message
code’.
This commit fixes that, and adds a handy formatter so it’s easier to do
the right thing in the future.
This makes it clearer we have tests for the code in forms.py, which
I missed initially. In future we could also split up forms.py in a
similar way, as it's currently _very long_.
As part of grouping tests for code in forms.py, I've extracted some
from test_validators.py, so that what remains is focussed on testing
the code in validators.py.
Daily volumes report: total volumes across the platform aggregated by whole business day (bst_date)
Volumes by service report: total volumes per service aggregated by the date range given.
NB: start and end dates are inclusive
