The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
At the moment we have a blanket rule that users can’t archive their own
services, to prevent someone accidentally deleting a real live service,
because that would be Very Bad.
But the tickets we get from users asking us to delete services are for
services they set up when they were just trying out Notify. There’s not
much harm in letting users delete these services, the consequences of
doing so are much lower than those of deleting a live service. And it
should mean fewer support tickets for us to deal with.
At the moment we have to update a YAML file and deploy the change to get
a new domain whitelisted.
We already have a thing for adding new domains – the organisation stuff.
This commit extends the validation to look in the `domains` table on the
API if it can’t find anything in the YAML whitelist.
This has the advantage of:
- not having to deploy code to whitelist a new domain
- forcing us to create new organisations as they come along, so that
users’ services automatically get allocated to the organisation once
their domain is whitelisted
"Failure is slower than success. So the longer a notification
takes to get a status, the more likely it is for that status
to be a failure anyway. This increases dramatically after 45 seconds.
The percentage of emails that go to delivered in less than 90 seconds
is 98.92%. To get to 99% we’d need to increase the timeout
to 178 seconds (3 minutes). We could still get 98.7% of notifications
by dropping the timeout to 45 seconds, and improve the experience
for notifications that are likely to fail by returning an error more quickly."
This removes the edit_folder_permission checks from the code, enabling
the folder permissions for all services.
This also fixes folder-related tests to set up appropriate user
permissions.
This should only be merged right after alphagov/notifications-api#2428,
when all other permission stories are done.
This adds an option on the organisation settings page to add
'request_to_go_live_notes'. When a service belonging to this
organisation requests to go live, any go live notes for the
organisation will be added to the Zendesk ticket in the 'Agreement
signed' section.
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
At the moment you have to wait for whoever you’ve invited to accept the
invitation before you can go live. Since this check is mainly for the
benefit of the service, not us, we should trust that people’s intentions
are good when they invite someone.
So this commit also checks the invited users when counting how many team
members a service has.
We shouldn’t be making services live without an agreement in place. In
order to have an agreement in place we need to know what organisation
operates the service.
If a service comes along but belongs to an organisation we don’t know
about then we should create that organisation. This commits removes the
link, which should force this to happen.
Settings looked at `domains.yml` when users were making go live requests
or email branding requests.
This will allow us to remove the `domains.yml` file, by using
information about organisations that is now stored in the database
instead.
Dealing with users who request to go live but haven’t completed all the
steps still represents a significant support overhead for our team.
We’ve made some improvements to the percentage of incomplete requests
with a better page design, but ultimately because it still shows the
button people think it’s OK to press the button while some of the items
on the page still say [Not completed].
We can do this now because organisations are in the database, which
means we can mark the agreement signed as soon as we get it back,
without having to deploy code.
We keep getting people requesting branding when they already have the
branding they want set. Seems like they don’t realise we’re doing it
automatically. This might help.
It:
- saves repetetive boilerplate code
- does some extra checks (eg checking for a `200` response)
- makes the codebase less confusing to consistently do the same thing in
the same way
Adds a front end for:
https://github.com/alphagov/notifications-api/pull/2417
> Sometimes we have to make a few services for what really is one
> service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also
> have our own test services which aren’t included in the count of live
> services. We currently count these as one service by not including
> them in the beta partners spreadsheet.
When we get a request for new branding it’s helpful to quickly see what
the service’s current branding is, so we can get a better sense of why
they want to change it.
It should be:
- if they have said they are going to send by a certain channel, show
the extra required task(s) for that channel
- if they haven’t said, infer from which templates they have
If you have email templates but haven’t told us what volumes you’re
sending we should assume you are going to send emails. We should only
stop asking you to add a reply-to address once you’ve told us for sure
you’re not going to send any emails.
This also applies to changing the text message sender – this should only
be hidden if you don’t have text message templates or you’ve said you’re
not going to be sending any text messages.
We have a number of go live requests where people have said they’re
sending text messages, but haven’t changed the text message sender from
the default of `GOVUK` (we ask teams who aren’t central government to do
this). At the moment we don’t prompt them to, because we look at whether
they have text message templates as indicative of whether they’re going
to send text messages.
Now that we explicitly ask for the volumes of text messages they’re
sending we should use this to determine whether or not we prompt them to
change their text message sender because it’s a stronger signal of
intent than what templates they’ve set up.
We have a number of go live requests where people have said they’re
sending email, but haven’t set up a reply-to address. At the moment we
don’t prompt them to, because we look at whether they have email
templates as indicative of whether they’re going to send email.
Now that we explicitly ask for the volumes of email they’re sending we
should use this to determine whether or not we prompt them to set up an
email reply to address because it’s a stronger signal of intent than
what templates they’ve set up.
At the moment it 500s because it can’t format the `None` values as
numbers.
In the future we will stop people requesting to go live until they’ve
provided this info. For now it has to be optional.
Things we talked about:
• asking users to write the number 'as numerals' or 'using digits' isn't
very plain English
• the style guide says to use an example in the error `..., like 5,000`
but not if you have an example in the hint text, so we can't do that
• I have reservations about 'correct format', because it sounds odd if
you're not describing something like a phone number, NI number or
credit card number.
Looking back through Request to Go Live tickets on Zendesk.
---
I got to September before I found anything that would count as invalid
under our new rules:
> Possibly around 1,000,000- not planning on implementing emails yet but
might change
I'll keep looking, but if most people enter the number according to the
hint example we might be able to go with a much simpler error just
prompting them to enter a number – no convoluted descriptions of what we
mean by a number
There seemed to be more problems when the Qs were about start volume and
peak volume. Users felt the need to explain their plans more.
Using 'number' instead of 'volume' is more explicit too – so that
probably helps.
In terms of errors:
`Enter the number of emails you expect to send`
`Enter the number of text messages you expect to send`
`Enter the number of letters you expect to send`
– will probably do it, right?
