Commit Graph

9 Commits

Author SHA1 Message Date
Tom Byers
aff584b933 Fix comparison in api_key component
We can't control the case of either 'name' or
'thing' so the comparison should make them both
the same.
2020-08-28 13:07:38 +01:00
Tom Byers
a0e78e6102 Changes to API key component
Changes the interface so:
- `name` is a required argument
- the heading is only shown if `name` and `thing`
  match

These changes reflect a pattern observed in how
the component is used in pages.

It's first worth stating what the `thing` and
`name` arguments are.

`thing` is the type of thing the id is, for
example an reply-to email address.
`name` is which one of that type in the page, for
example the reply-to email address for user 1.

In pages where the id is the only one of its type,
these will have the same value.

When it is the only one of its type in a page, it
always has a heading so this makes the heading
appear based on `name` matching `thing`.
2020-08-25 10:54:42 +01:00
Tom Byers
7fd034a83f Change how live region works with API key JS
Includes implementation of new code on Reply-to
email addresses page.

The existing code put the live region on the
module element so the id and button were
read out when the state changed.

The report from the Digital Accessibility Centre
(DAC) said screenreader users were confused by the
content changing because it wasn't announced.

These changes attempt to make the state changes
clearer by:
1. moving the live region out into a separate
  element so we can better control what is
  announced
2. adding hidden text around to the button and text
  above (sometimes the id, sometimes the 'Copied
  to clipboard' text) to give more context

When the id is copied to clipboard, the button
changes but this is not announced as the
live-region text takes precedence (due to being
set to 'assertive'). Because of this, hidden text
has been added in change 2 to explain what the new
button does.
2020-08-25 10:54:42 +01:00
Katie Smith
0d0b71af63 Update buttons on api key pages to govuk-frontend buttons 2020-02-17 08:05:05 +00:00
Chris Hill-Scott
b68784207b Add email reply address to ID to the page
The first users of multiple email reply to addresses will be using the
API. This means that the need to be able to specify the ID of the reply
to address they want.

We chose to implement it like this instead of by passing the address in
directly because that means deploying code. For some teams deploying
code can take weeks, and we’d like to let teams have the flexibility to
make changes faster than this.

Same as for templates, you shouldn’t have to go to the _edit_ page in
order to get the ID. This means listing them on the page where you see
all the reply to addresses.

Listing the IDs like this means that it’s not really a table any more,
because the information isn’t organised in columns. So I think it makes
sense to reuse the pattern from the manage team page, which has a
similar relationship between the information.
2017-09-28 10:42:04 +01:00
Chris Hill-Scott
ffab83729c Make screen reader announce when API key is copied
Currently screen reader users would click the ‘Copy API key’ button but
not get any feedback. This commit adds an ARIA attribute which tells the
screenreader to announce any changes in to the content of the element
(eg when it changes from showing the API to showing the text ‘API key
copied to clipboard’).
2017-02-14 11:50:12 +00:00
Chris Hill-Scott
27ad1532e4 Make the flow of using templates better
For users who:
- want to send messages from a template
- want to edit templates

For developers:
- who need to get the ID of a template

This commit mainly cleans up the choose template page so there are less
options, and the options that are there are less wordy.

This means:
- moving ‘send yourself a test’ onto the send messages page, and making
  it button
- stripping a lot of stuff out of the ‘send from API’ page, so it’s more
  obvious what the template ID is
2016-04-19 15:31:19 +01:00
Chris Hill-Scott
9784a9936c Add pages for create/view/revoke API keys
Copying what they’ve done on GOV.UK Pay, we should let users:
- generate as many keys as they want
- only see the key at time of creation
- give keys a name
- revoke any key at any time (this should be a one way operation)

And based on discussions with @minglis and @servingUpAces, the keys should be
used in conjunction with some kind of service ID, which gets encrypted with the
key. In other words the secret itself never gets sent over the wire.

This commit adds the UI (but not the underlying API integration) for doing the
above.
2016-01-20 16:22:23 +00:00
Chris Hill-Scott
c4544eb833 Add API key component
This commit adds a component for showing an API key. Usage:

```jinja
{{ from 'components/api-key.html' import api_key }}
{{ api_key('e1b0751388f3cd0fc9982c701acdb3c2') }}
```

Depending on the user’s browser, it works in three different ways.

No Javascript
---
The API key is shown on the page.

Older browsers with Javascript
---
The API key is hidden, and users can click a button to reveal it.

Newer browsers that support copying to clipboard without Flash
---
As above, but when the key is shown there is a button which copies it to the
clipboard. This is acheived by using
[this polyfill](https://www.npmjs.com/package/query-command-supported)
to reliably detect browser support for the ‘copy’ command.

The styling of the component is a bit different to the initial sketch. I think
a grey button works better than green. Green feels like it’s going to take you
somewhere else.
2016-01-17 09:39:09 +00:00