darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-02-16 08:24:28 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
a088409dfeba315d3719e9e6d147ddf96cd75b0f
notifications-admin/app/templates/views/api/keys.html

69 lines
2.2 KiB
HTML
Raw Normal View History

Added main nav to logged in pages
2015-12-14 16:53:07 +00:00
{% extends "withnav_template.html" %}
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-19 09:55:13 +00:00
{% from "components/table.html" import list_table, field, hidden_field_heading %}
Add GOV.UK Design System style back links 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.
2019-04-29 11:44:05 +01:00
{% from "components/page-header.html" import page_header %}
Committing before merge
2023-08-30 11:07:38 -04:00
{% from "components/components/button/macro.njk" import usaButton %}
{% from "components/components/back-link/macro.njk" import usaBackLink %}
Added the shell API keys page [ci skip]
2015-11-30 16:20:45 +00:00
Include service name in page `<title>` In pages specific to a service (e.g. dashboard and sub pages) the title needs to distinguish which service it applies to. This is mainly to give context to screen reader users who could be managing multiple services. Implementing this uses template inheritance: `page_title` includes `per_page_title` includes `service_page_title` ‘GOV.UK Notify’ is inserted into every page title. Pages that set `service_page_title` get the service name inserted too.
2017-02-13 10:45:15 +00:00
{% block service_page_title %}
API keys
Added the shell API keys page [ci skip]
2015-11-30 16:20:45 +00:00
{% endblock %}
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{% block backLink %}
Committing before merge
2023-08-30 11:07:38 -04:00
{{ usaBackLink({ "href": url_for('main.api_integration', service_id=current_service.id) }) }}
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{% endblock %}
Added main nav to logged in pages
2015-12-14 16:53:07 +00:00
{% block maincolumn_content %}
Added the shell API keys page [ci skip]
2015-11-30 16:20:45 +00:00
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{{ page_header('API keys') }}
Use confirmation banner for revoking API keys Currently revoking an API key takes you to a separate page. It should work the same way as other destructive actions, ie staying on the same page but with a banner asking you to confirm the action.
2017-07-24 15:36:38 +01:00
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
<div class="body-copy-table">
{% call(item, row_number) list_table(
Put API keys on service model Similar to how we put templates on the service model, it means less logic needs to happen in the view code.
2018-11-07 11:35:24 +00:00
current_service.api_keys,
Replace haven't with have not
2019-09-13 12:54:56 +01:00
empty_message="You have not created any API keys yet",
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
caption="API keys",
caption_visible=false,
field_headings=[
'API keys',
'Action'
],
field_headings_visible=False
) %}
{% call field() %}
<div class="file-list">
{{ item.name }}
<div class="hint">
{% if item.key_type == 'normal' %}
Live – sends to anyone
{% elif item.key_type == 'team' %}
Rename ‘whitelist’ to ‘guest list’ in UI This commit changes all the places where a user would see the term ‘whitelist’ in the content of page to say guestlist instead. We’re removing the term ‘whitelist’ for two reasons. The first reason is that we agree with the National Cyber Security Centre say: > It's fairly common to say whitelisting and blacklisting to describe > desirable and undesirable things in cyber security. For instance, when > talking about which applications you will allow or deny on your > corporate network; or deciding which bad passwords you want your users > not to be able to use. > However, there's an issue with the terminology. It only makes sense if > you equate white with 'good, permitted, safe' and black with 'bad, > dangerous, forbidden'. There are some obvious problems with this. So > in the name of helping to stamp out racism in cyber security, we will > avoid this casually pejorative wording on our website in the future. > No, it's not the biggest issue in the world - but to borrow a slogan > from elsewhere: every little helps. – https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white The second reason is that we’ve observed some users think that they have to put recipients in the whitelist even when they’re already with in the team. We think that the term ‘whitelist’ might be reinforcing this mental model because of how ‘whitelists’ might work in other applications. We considered the following alternatives or concepts: - Development - Recipients - Sandbox - Extended team - Smoke test recipients - Allowed - Nominated - Bonus - Additional - Safe - Team list - Trusted contacts - Designated people - Guest list - Team key list We also considered not giving it a name, and explaining it as a nuance of how the team key works. After mocking this up it felt more disjoined. We think it’s still useful for the thing to have a name so that it’s easy to refer to between the docs and the UI. We like the term ‘guest list’ because: - of how it sits with team members – members and guests in the abstract - a guest list is a concept that a lot of people will be familiar with – a list of people who can access a thing - ‘guest’ is very different to ‘recipient’ – we want to mitigate any confusion between this and the (emergency) contact lists
2020-06-12 09:00:08 +01:00
Team and guest list – limits who you can send to
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
{% elif item.key_type == 'test' %}
Test – pretends to send messages
{% endif %}
</div>
</div>
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-19 09:55:13 +00:00
{% endcall %}
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
{% if item.expiry_date %}
{% call field(align='right') %}
updated datetimes based on style guide
2024-03-18 15:10:26 -07:00
<span class='hint'>Revoked {{ item.expiry_date|format_datetime_table }}</span>
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
{% endcall %}
{% else %}
{% call field(align='right', status='error') %}
- Removed links to the gov uk stylesheets - Deleted /stylesheets folder - Removed sass build from gulpfile - Changed gov links to usa links - Changed other govuk styles, like breadcrumbs - Changed name of uk_components file to us_components - Fixed a few tests that broke on account of the changes
2023-08-08 16:19:17 -04:00
<a class="usa-link usa-link--destructive" href='{{ url_for('.revoke_api_key', service_id=current_service.id, key_id=item.id) }}'>
Test passed, good time to commit
2023-06-16 14:55:24 -04:00
Revoke<span class="usa-sr-only"> {{ item.name }}</span>
Add descriptive links to API keys page The links had no descriptive text, so all read 'Revoke'. This adds hidden text specific to the item they relate to.
2021-02-23 14:53:33 +00:00
</a>
Use 19px not 16px type in more places Making the navigation narrower means that we have more space on every page. So on pages where we had to use 16px type just to fit stuff on the page we can now bump the type size up to something less miserly. This is mainly the team and settings pages. We still need to use 16px on pages which list notifications or previews of spreadsheets, because we’re still trying to fit a lot of information onto these pages, so every little space-saving helps.
2017-03-15 12:50:45 +00:00
{% endcall %}
{% endif %}
{% endcall %}
</div>
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-19 09:55:13 +00:00
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
<div class="js-stick-at-bottom-when-scrolling">
Committing before merge
2023-08-30 11:07:38 -04:00
{{ usaButton({
Replace straightforward buttons and links styled like buttons This replaces the buttons that aren't part of a macro and that we don't need to write additional styles for with their govuk-frontend equivalent. There were some links that were styled to look like buttons, so these have also been replaced with the new govuk-frontend macro. There was one button on the `choose-account.html` template that was in a section of code that was never reached - this has been deleted.
2020-01-30 14:01:13 +00:00
"element": "a",
"text": "Create an API key",
"href": url_for('.create_api_key', service_id=current_service.id),
"classes": "govuk-button--secondary"
}) }}
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
</div>
Use the API key pattern for showing service ID When we show an identifier, like an ID or a key, we have a pattern which adds a ‘copy to clipboard’ button. We weren’t using this pattern for service ID. This commit also moves it under the table, so hopefully people will be less likely to confuse the service ID for an API key when scanning down the page.
2016-04-25 09:48:26 +01:00
Added the shell API keys page [ci skip]
2015-11-30 16:20:45 +00:00
{% endblock %}
Reference in New Issue Copy Permalink