We need users to have created some templates before they go live, so we
can see what kind of messages they intend to send.
We can do this automatically based on the work done in
https://github.com/alphagov/notifications-admin/pull/1892
One of the things that we want to check before a service goes live is
that they have at least two team members with the manage service
permission. Anyone who can make a request to go live has this
permission, so that means one additional user is needed. This is what we
can automatically communicate to the user.
Under the hood this makes use of the logic added in
https://github.com/alphagov/notifications-admin/pull/1891
There’s over 1000 domains in our file. This is too much for parametrize
to handle when running the tests on multiple cores. End up with this
error:
```
Different tests were collected between gw1 and gw2.
```
We only sign agreements for a whole council. Therefore we know that if
a council isn’t one of the ones who has signed an agreement, no part of
that council has signed the agreement, therefore it’s a `false` not a
`null`.
The thing that matters for which agreement an organisation has to sign
is whether or not that organisation is crown or non-crown.
There is only a partial overlap between crown/non-crown and
local/central. We can’t infer one fro the other. So this commit makes it
explicit by marking all local government organisations as non-crown,
which is something we can know for sure.
We don’t, for example, know the inverse, that all parts of all central
government organisations are crown bodies (but we can mark some of them
as being so later on).
The list of email domains is a different list from the list of all
government domains. And because the list of all government domains is
really long now, it could be unnecessarily slow to search through when
(a lot of the time) all we care about is whether the email address ends
with `.gov.uk`.
This means we’ll be able to tell them for sure that they don’t need to
signed it again.
List taken from looking through the folder of signed agreements on
Google Drive.
This adds information about which orgs have signed an MOU to the domain
list. The meaning of the attribute is:
- `true`: MOU signed for the whole organisation
- `false`: no MOU for any part of the organisation
- `null` (or missing): can’t be sure if it’s true or false
This commit:
- makes the logic around looking up a domain a bit more sophisticated
by matching on the longest domain name first
- exposes the details about an organisation to consumers of the
`GovernmentDomain` class
In some cases we can tell based on someone’s email domain whether they
work for a central or local government organisation, and whether they
will need to sign the MOU or agreement in order to go live. So this
commit creates a structure to store this information.
Makes it fiddlier to add new domains, and is only needed to generate the
regular expression. Much cleaner to just insert them as part of
generating the regular expression.
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).
Users who have the ‘manage API keys’ permission can see the settings
page. But they don’t have permission to request to go live.
At the moment they can still see the link, though clicking it gives them
a 403 error. This commit changes it so that they can’t see the link, and
tells them who they should speak to about going live (their manager).
We have tickets from people asking how long the process takes. I suspect
that this is because they’re not getting to the bottom of the form
before they’re ready to go live.
A lot of users aren’t reading or paying attention to the checklist on
the request to go live page. We think that we can get more people to
read it by putting it on its own page, where users won’t jump straight
to filling in the form.
This will, later on, let us make this page smarter by automatically
detecting if they’ve done the necessary things.
