We want GPs to be able to accept the agreement online. But at the moment
they don’t get automatically assigned to organisations. So we need to
let them enter the agreement accepting journey even if they don’t have
an organisation set up.
of course it's logged in, it's a platform admin
also, reduce use of the `client` fixture in test_platform_admin
(replace it with platform_admin_client)
We added `Upload letters` to the platform admin service settings, which makes is confusing when next to `Upload documents`.
Also `User auth type editting` is a confusing label
`User auth type editting` --> `Email authentication`
`Uploading documents` --> `Send file by email`
It’s possible to delete default letter contact blocks because there is a
fallback – having a blank letter contact block. This is different to SMS
senders and reply to addresses.
For this to make sense it also means:
- adding the ‘blank’ letter contact block to the list of letter contact
blocks
- having a way of setting the default back to being blank
The service organisation type will either be the same as the org type of
the service's organisation or will be set by a user when creating a new
service. This removes the ability to change it from the platform admin
settings table.
This makes it consistent that an option which contains more options has
a hint about how many options it contains.
Also adds a formatter to get us ready for 1,000 services 🎉
If you’ve come from a template to add a new letter sender then it’s
because you want those words on that template. This commit adds the
extra API call to make that happen.
Most users don’t have multiple contact blocks. So by default it should
feel like you’re just editing the one contact block, rather than
managing a collection of them. So this page skips the ‘choose’ page when
the user doesn’t yet have any contact blocks.
The ‘make this default’ checkbox should be shown, except when:
- the user is adding their first email reply to address (because the
first one has to be the default)
- they’re editing the existing default (because they can’t change it
to be not default)
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.
