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.
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.
AJAX requests stop on success or failure, as the waiting page
does not have to referesh any longer.
Also on failure a form that allows user to try again
is shown.
The `getSharedAttributes` method gathers all
attributes, and [DOM tokens](https://developer.mozilla.org/en-US/docs/Web/API/Element/classList)
in the `class` attribute not controlled by the
module for re-applying in the `render` method.
Because it gathered them for all items, many
duplicates ended up being added to new items.
Browser engines were tidying up the duplicates
but we shouldn't be adding them in the first
place.
Also removes setting of the `$` variable to
jQuery.
This can mess up the unit tests if they run
against JSDOM, which doesn't set the global `this`
to `window`, as browsers do.
We don't set `$` in any other module scripts and
adding it to `this` without making explicit that
`this` means `window` isn't useful.
Running the sticky JS in Jest raised errors due to
these variables not being assigned properly.
It's JavaScript so any variable not defined by the
`var` prefix will automatically become a property
of the global object. That is not what is intended
by the code so requires changing.
This is for use in the folder permissions UI. It’s designed to be sized
at the same width as a GOV.UK style checkbox. The CSS to render it is
something like:
```css
background-image: file-url('folder-black.svg');
background-repeat: no-repeat;
background-size: 39px auto;
background-position: 0px 4px;
```
Live regions need to be in the original HTML of
the page to work. We were generating the summary
in JS.
This changes the JS to only generate the contents
of the summary so changes to its contents are
announces by the existing live-region.
Expands the API of the macro to allow nested
checkboxes to have a summary tracking the current
selection, the fieldset to expand/collapse and
buttons to be added to allow jumping between
states.
Includes making 'Done' button inline on mobile.
Helps differentiate it form the form submit.
We use ‘back’ to label a control which navigates to a previous page now.
It could be confusing to keep this control labelled the same way. And
in the future the folder permissions interaction definitely shouldn’t be
using ‘back’, because it suggests undoing the selection you’ve made.
For the upcoming user permissions enhancements we want to differentiate
between actions that take the user to a new page (eg changing a user’s
phone number or email address) and actions that reveal extra controls in
the current page (which will be changing the folders a team member can
see).
This change will be inconsistent with the interaction for scheduling a
job, which uses links to reveal other controls in the page.
This commit changes the scheduling interaction to use grey ‘secondary’
buttons for revealing extra controls in the page, for consistency with
the upcoming folder permissions work.
Since we added template folders the templates page has had a ‘medium’
sized heading, where other pages have stuck with a ‘large’ size.
This commit rationalises the decision around which pages have which
heading size:
- ‘navigation’ pages (eg templates, team members, email reply to
addresses) have medium sized headings
- transactional pages (ie ones which have a green button) keep the
larger heading size
We’ve stopped using them in favour of putting any ‘back’ link at the top
of the page. This commit removes them from the macro to make sure we
don’t accidentally reintroduce them.
The GOV.UK Design System back link component is sized (roughly) to the
contain the text and icon. Presumably this is so it’s safe to use in
various contexts.
Since we have control over the context is which it’s used, we can get
away with making the click area larger – in accordance with Fitt’s law –
without risking overlapping other page elements.
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
The right aligned cells contain ‘Change’ links. These have a large
`border` to make the clickable area bigger. This commit removes the
`overflow: hidden` from these cells, so that the larger border remains
visible.
I think this is something we inherited from the Digital Marketplace
code. We only use this for organisation settings are the moment, but
the list markers are redundant because each item will never wrap onto a
new line; it will truncate instead. Still keeps a little sliver of
spacing just so it doesn’t look like a paragraph.
Most of the content of our ‘settings’ tables is in the value, not the
key. The value is in the middle column. So we should allocate the most
space to the value.
The previous layout was based on the premise that most pages divided the
grid like this:
```
_______ _______ _______ _______ _______ _______ _______ _______
| 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 |
| | | | |
| 2/8 | 2/8 | 2/8 | 2/8 |
| | | | |
|–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––|
| | | |
| | 3/8 | 3/8 |
| | | |
| |–Label–––––––––––––––––|–Value––––––––––––Link–|
| | | |
|_______________|_______________________|_______________________|
```
This was because a lot of pages had a left column for emails, and a
right column for text messages, so it felt consistent for tables to
always default to 50% of the width of the main column.
This consistency has faded with time, especially as we added letters.
So this commit changes these tables to allocate more space to the
central column, but still sticking to the grid like this:
```
_______ _______ _______ _______ _______ _______ _______ _______
| 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 |
| | | | | | | | |
| 2/8 | 2/8 | 4/8 |
| | | |
|–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––|
| | | | |
| | 2/8 | 3/8 | 1/8 |
| | | | |
| |–Label–––––––––|–Value–––––––––––––––––|–––Link|
|_______________|_______________|_______________________|_______|
```
Since there’s more space to display the value of a setting this commit
also truncates settings that are too long to fit in the width of the
column (for example a long email address) rather than the previous
behaviour of truncating them. This all just makes things look a bit
cleaner.
