Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
One of the things we need to know for a service to go live is whether
they have at least two users with the ‘manage service’ permission.
So this commit adds a method to the client to count how many users have
a given permission. We can do logic on this count later. But having the
counting done in the client feels like a cleaner separation of concerns.
Meant some refactoring of the way `service_id` is extracted from the
request, in order to make it easier to mock.
When users request to go live we check stuff like:
- if they’ve added templates
- if they have email templates (then we can check their reply to
address)
This commit adds a method to do this programatically rather than
manually.
We _could_ do this in SQL, but for page that’s used intermittently it
doesn’t feel worth the work/optimisation (and the client method is at
least in place now if we do ever need to lean on this code more
heavily).
Notifications-api now needs the service_id to check the uniqueness of
the service name when trying to change it. This is to allow a user to
successfully change the pluralization or the case of their service name.
It’s confusing showing green ticks for cancelled invites. This commit
changes the appearance so that only pending or active users (ie those
that could actually do some damage) get green ticks.
Also fixes missing edit links caused by instances of `User` having
`.state` but instances of `InvitedUser` having `.status`.
Right now these are two separate lists. Which makes it harder to add
improvements that will make large numbers of users easier to manage.
When we’re doing user research we often:
- start the task by inviting the participant to a service on Notify
- have them use a prototype version of the admin app, hosted on a
different domain
Currently we can’t do both of these things together, because the invite
emails always send people to notifications.service.gov.uk (because it’s
the API that sends the emails, and the prototype admin app points at the
production API).
This commit changes the admin app to tell the API which host to use when
creating the invite links.
Depends on:
- [ ] https://github.com/alphagov/notifications-api/pull/1515
- Updated tests and added a new mock_get_monthly_template_usage
- Deleted get_monthly_template_statistics_for_service
- Added new test to test the redirection of the old endpoint
The current template-activity page is slow as it is using the end point
which uses notification_history and hence is timing out. This adds a
new pages (so that they can be compared side by side) which will be
hidden until is is approved with the larger data set and tested.
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
`prefix_sms_with_service_name` is a computed attribute on the service
model. It’s where we get the value from, and the API does some work to
get it from the database, or derive it from the default SMS sender.
It can’t be updated, because it’s not itself a database column.
`prefix_sms` is the name of the actual database column. This is the
thing that we need to update.
This will go away eventually.
We’re extracting this from being determined based on what the sender
name is to its own setting.
This commit will let users set it independently.
Until the explicitly set it, it will still be determined based on
whether their default sender name matches the default for the platform.
we unpack the api invited user rest endpoint results straight into the
InvitedUser object, so we should make sure that any fields added to
the api response are mentioned here
Different parts of government get billed slightly differently, and
there’s differences in how much money we’re allowed to give them.
Think these numbers are right, but should be double checked.
So that we can default services to their appropriate text allowance, we
need to find out what sector they're in. So let's start collecting that
from teams as they create new services.
I think Central/Local/NHS are the right options, but these can be easily
changed if not.
