so that platform admins (us) can view pages as regular users do easily.
Simply adds a flag in the session cookie that overrides the actual
platform admin flag on the user model if set. This way it's safe, since
this only downgrades existing functionality, so if someone managed to
alter it they could only get less permissions, not more.
You can change this value from the user profile page if either:
* you're a platform admin
* the flag is set (to any value) on the cookie.
This slightly weird check means that we don't check the underlying
`user._platform_admin` flag anywhere in the code, even when toggling
the suppression.
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.
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.
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)
This code wasn’t taking into account that you might have sent letters
in the month.
The dash is only there to space out months which don’t have any usage
in them.
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.
