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 🎉
Most users don’t have multiple contact blocks. So by default it should
feel like you’re just editing the one contact block, rather than
managing a collection of them. So this page skips the ‘choose’ page when
the user doesn’t yet have any contact blocks.
Also add more tests for showing or not the cancel those letters link
Also check if all notifications already in database
Upgrade delete button text logic to handle more cases
Also corrections following review
It looks weird to have two different visual treatments for showing a
navigable hierarchy.
I reckon losing the slash won’t make things less folder like – Windows
for example uses chevrons as foler separators.
It was a bit inconsistent depending on whether there was/wasn’t a search
box or channel tabs on the page.
I found this just too complicated to do in pure CSS, so added a new
spacing class which gets toggled on and off.
This commit aligns and spaces elements on the page to show which are
related to others.
This needs some adjustment now because we potentially have more things
on the page now – we need to make space for them.
Service names can be quite long. Organisation names can be quite long.
Together they can be very long. This isn’t great because:
- sometimes they overflow the width of the container, which looks broken
- even if they’re not that long they can make the UI look quite
cluttered
This commit restricts them to widths that should stop the above from
happening. In the case of the organisation name the width has
specifically been chosen to line up with the ¼ and ¾ column grid
used by the navigation.
Currently we set not-very-useful defaults for organisation type and
crown status when creating an organisation. This commit adds two field
to the form (in addition to the existing name field) to explicitly ask
for:
- organisation type
- crown status
We need these for all organisations before we can make any of their
services live.
This commit also records any new organisation as not having accepted the
data sharing and financial agreement, because if we don’t know about the
organisation already then they definitely won’t have signed it.
A user might not have a guessable organisation type, even if the service
they’re working on does have an organisation set. This can happen for
users with @nhs.net email addresses, for example.
If we’re not sure whether a user belongs to a crown organisation or not
we want to fix that before.
This is a last-ditch fallback because we shouldn’t be adding new
organisations without also setting their crown status.
Platform admin users can still see the organisation breadcrumbs for
trial mode services, but others uses can only see organisation
breadcrumbs for live services.
Organisation team members only have access to the dashboard if they’re
also a member of that service.
They always have access to the usage page, so let’s link there instead.
Organisation team members will be ultimately interested in the detailed
usage of each service, but shouldn't necessarily have access to the
personal data of that services users.
So we should allow these organisation team members to navigate to live
services usage page from the organisation page. They may need to contact
the team so they should also be able to view the team members page.
So they'll then see just usage and team members pages.
If they are actually a team member of the service they're viewing, then
they'll see the full range of options as usual.
This commit implement the above by adding an extra flag to the
`user.has_permissions` decorator which allows certain pages to be marked
as viewable by an organisation user. The default (for all other existing
pages) is that organisation users don’t have permission.
Added a breadcrumb link to a service's organisation to the
withnav_template. This will only show if a service has an organisation
and the current user is also a member of that org, or the current user
is a platform admin user.
Also removed a couple of unused fixtures from the client_request
fixture.
When someone selects that they are accepting the agreement on behalf of
someone else then they need to provide that person’s details. Otherwise
they shouldn’t care about these extra fields.
This commit uses the progressive disclosure pattern from the GOV.UK
Frontend Toolkit to hide the additional fields unless someone selects
the relevant radio button.
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.
If it’s something weird like an instance of a Python object let’s ignore
it (else we get invalid HTML like
`id='<notifications_utils.columns.Cell object at 0x1126f4e80>'`).
