If the user has selected that they are accepting the agreement on behalf
of someone else then we need to make the they provide that person’s
details.
If they’ve selected that they are accepting the agreement themselves
then we have to ignore what they might have put in the ‘on behalf of
boxes’ (for example if they filled them out but then changed their
mind).
At the moment, the process for accepting the data sharing and financial
agreement is:
1. download a pdf
* print it out
* get someone to sign it
* scan it
* email it back to us
* we rename the file and save it in Google Drive
* we then update the organisation to say the MOU is signed
* sometimes we also:
* print it out and get it counter-signed
* scan it again
* email it back to the service
Let's not do that any more.
When the first service for an organisation that doesn't have the
agreement in place is in the process of going live, then they should
be able to accept the agreement online as part of the go live flow. This
commit adds the pages that let someone do that.
Where the checklist shows the agreement as **[not completed]** then
they can follow a link where they can download it (as happens now).
From here, they should then also be able to provide some info to accept
it. The info that we need is:
**Version** – because we version the agreements occasionally, we need to
know which version they are accepting. It may not be the latest one if
they downloaded it a while ago and it took time to be signed off
**Who is accepting the agreement** – this will often be someone in the
finance team, and not necessarily a team member, so we should let the
person either accept as themselves, or on behalf of someone else. If
it's on behalf of someone else we need to the name and email address of
that person so we have that on record. Obvs if it's them accepting it
themselves, we have that already (so we just store their user ID and
not their name or email address).
We then replay the collected info back in a sort of legally
binding kind of way pulling in the organisation name too. The wording
we’re using is inspired by what GOV.UK Pay have. Then there’s a big
green button they can click to accept the agreement, which stores their
user ID and and timestamp.
The scrollable tables code styles some of the cells in the target table
by looking for the `table-field-center-aligned` class.
This class was renamed in 0512f40ad3
This commit updates the scrollable tables code to refer to the new
classname, which means that things should line up properly when drawing
the table.
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 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.
