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 🎉
In reality we shouldn’t have any live services that don’t have an
organisation. But we probably do locally, in preview, etc., and we
shouldn’t lose a way of accessing them.
We think users fall into three buckets:
Has access to a few live services, no organisations
--
In this case they user will just see the list of live services they have
access to – pretty straightforward.
Has access to all live services, plus the organisation
--
Conceptually the live services are part of the organisation, whereas the
trial mode ones aren’t. So it makes sense to go through the organisation
to see the live services. If we listed the live services on the choose
service page then we’d be confusingly duplicating them on the
organisation page.
Has access to the organisation, but no services
--
The user doesn’t have direct access to their organisation’s services, so
they need to go to via the organisation page to change service.
For both of the latter we’ll be providing a quick breadcrumb route back
into the organisation, so most of the time they won’t need to use the
choose service page at all.
At the moment the service list doesn’t disambiguate between live and
trial mode services. This makes it hard to tell which of the things are
important and which aren’t.
The first step towards making this page clearer is to list trial mode
services separately.
It’s annoying having to go through the slow-to-load platform admin index
page to get to organisations. And it makes more sense for them to be
in the same place as other organisations and services that you can see.
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.
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.
This can happen if you click a link for a service you don’t have access
to. We shouldn’t show the back to service link in this case because:
- you shouldn’t be able to find out the service’s name from just knowing
the link
- if you click the link you only get a `403` anyway
This commit is the first step to disentangling the models from the API
clients. With the models in the same folder as the API clients it makes
it hard to import the API clients within the model without getting a
circular import.
After this commit the user API clients still has this problem, but at
least the service API client doesn’t.
When you’re not signed in you can still have a service in your session.
But there’s no point trying to get to its dashboard until you’re signed
in – you’ll just be sent back to the ‘sign in’ page.
we were seeing isort produce different outputs locally and in docker -
this was due to it having different opinions about whether the tests
module (ie all our unit tests) is a first party (local) or third party
(pip installed) import. It's a first party import, so by defining this
in the setup.cfg isort settings, we can force it to be consistent
between environments.
Note: I don't know why it was different in the first place though
