This should make the ‘All organisations’ page load a lil’ bit quicker.
Still worth caching the domains separately so the response is smaller
when we only care about domains. This is because the code that uses the
domains is part of the sign up flow, so it’s really important that it’s
snappy.
This allows us to split the page into sections without over-using bold
fonts. And it means that when the user clicks into a service from this
page the column layout stays the same 1/4 – 3/4, rather than jumping
about so much.
The view code shouldn’t need to know the internals of a service’s data
structure; the idea of having a service model is to abstract this kind
of thing.
This makes it:
- nicer, by having access to sensibly named things like
`Service.trial_mode` instead of `service['restricted']`.
- less likely to write Jinja code like `service.trail_mode`, which would
fail silently if `service` was a dictionary
For consistency with `.organisations`/`.organisation_ids`.
`.services` returns a list of semi-rich dictionaries for each service.
`.service_ids` returns service IDs only.
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.
If the user doesn’t belong to any organisations then the only live
services they can see are the ones they directly have access to. So
let’s list these above the user’s trial mode services (because they’re
more important).
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.
Changed this yesterday. Changing it again now because I think it’s
confusing.
There’s really no going ‘back’ once you’ve sent a message – you can’t
undo it. If you want to get back to the template you used, well, that
link is in the page.
This commit changes the back link logic so it only appears when you’ve
navigated to a notification, not when you’ve just sent it.
The API needs the id of the user, not the id of the invite.
The problem with the tests is that the update mock returned a different
user ID than the user it was being passed. So the tests didn’t catch
this.
This fixes the bug where if you have three placeholders:
> ((one)) ((two)) ((three))
The first one you are asked to fill in is `((three))` (ie
`template.placeholders[-1]`).
This reintroduces a bug where if you use the ‘Use my phone number’ link
you skip straight to filling in `((two))` and can never proceed because
you’re never given the chance to fill in `((one))`. This commit also
fixes that bug.
If the user wants to go back from here they need to be sent back to the
start of entering the placeholders, because we won’t have their previous
personalisation in the session still
I think the back link on this page was introduced by accident. But it’s
good to still have it on this page, because it keeps consistency with
the previous pages.
Users can only be archived by Platform Admin from the user page
(/users/<user_id>). This removes them from all services and orgs and
updates their details.
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 api always returns exactly:
```
id
name
email_address
auth_type
current_session_id
failed_login_count
logged_in_at
mobile_number
organisations
password_changed_at
permissions
platform_admin
services
state
```
it does this through `models.py::User.serialize` – there is an old
Marshmallow `user_schema` in `schemas.py` but this isn’t used for
dumping return data, only parsing the json in the create user rest
endpoint.
This means we can rely on these keys always being in the dictionary.
