Our other models inherit from `JSONModel`, rather than manually doing
lookups of the JSON in the `__init__` method. This commit changes the
user model to work in the same way.
I had to add a new concept (`DEFAULTS`) to account for some properties
not always being present in the (mocked) JSON. In reality it might be
that the API does always return these values. This should be looked at
in future work, to see which defaults can be safely removed. At least
now they:
- do not mean any changes are needed to the existing tests
- are explicitly separated from the attributes that we do expect to
always be in the JSON response
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.
Got some advice from the content community:
> I don't think we have a style on this - it doesn't really come up on
> GOV.UK mainstream.
>
> In your example, I'd go with something like 'less than £250 before
> VAT' or 'less than £250 (not including VAT)' to make it as clear as
> possible. Would that work?
I’ve gone with ’less than £250 (before VAT)’. I noticed that elsewhere
we’ve said ‘Each message costs 1.58 pence (plus VAT)’ so that feels
fairly consistent.
Pages within a service use a 2/8, 5/8, 1/8 grid.
The content pages use a 1/4, 3/4 grid, for consistency with the product
page template.
But I feel like the internal consistency is more important, and it feels
weird for the main content column to jump about.
So that you don’t have to use the footer navigation to switch between
these related pages. Matches the template we use for organising
features-related content.
When a user deletes their service we take them to the ‘Choose service’
page. Like other non-service-specific pages this has a link to the last
service you were looking at. But in this specific case the last service
you were looking at is the one you’ve just deleted. Which means the link
is confusing because:
- you thought the thing was ‘gone’
- we’ve secretly renamed it to ‘_archived Example service name’
So this commit hides the link in this specific case.
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 the only setting that a normal organisation team member
can change is the name of the organisation is its name. And we don’t
even want them to be able to change this. So this commit hides the
settings page entirely for non-platform-admin users.
If a domain is already in our organisation list then we no longer need
to manually update it here. As part of this process I went and
proactively added some organisations, so I could remove more of them
from this file. I only did this where I could clearly determine from the
domain or a suppot ticket what the organisation was.
The domains lookup is a bit slow because it’s serialising all the
organisations in the database. Since we’re putting this in the sign up
flow it should feel snappy, so lets cache just the domain bit of it in
Redis.
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
first way round and then collected placeholders again. Now the flow
collects all placeholders in one round.
Also fix the back link for step-1 for test flow so it goes back
to choosing recipient number
Also move operators around following flake8's advice :)
"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."
