darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-07-04 00:18:52 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
d94f324b82ef78f5293fcdbca3cd005a9aaebdec
notifications-admin/app/templates/views/api/keys/create.html

38 lines
1.1 KiB
HTML
Raw Normal View History

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
{% extends "withnav_template.html" %}
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 %}
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/page-footer.html" import page_footer %}
Always show live key, reword key labels This is trying to resolve these confusions: - that you’re in trial mode, which means you can’t have a live key yet ( or you can but it wont work, which is what we used to have) - what does simulate mean The create key page is the right place to resolve these confusions because it’s where users are actively reading. This commit also removes the trial mode banner from API integration page because this where users _aren’t_ actively reading. A whole bunch of users weren’t seeing this banner at all. The implementation of the disabled API key options is kinda clunky because WTForms doesn’t have a native way of doing this. ¯\_(ツ)_/¯
2016-11-01 15:34:04 +00:00
{% from "components/banner.html" import banner_wrapper %}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% from "components/form.html" import form_wrapper %}
Committing before merge
2023-08-30 11:07:38 -04:00
{% from "components/components/back-link/macro.njk" import usaBackLink %}
Migrate GOV.UK components to USWDS - Convert previous/next navigation to USWDS pagination component - Update radio buttons and checkboxes to use USWDS classes - Migrate guest list inputs with proper USWDS styling - Replace GOV.UK button patterns with USWDS button variants - Update form field spacing to use USWDS utilities - Scope fieldset legend styles to specific form contexts - Update visual regression test references for new components
2025-07-30 15:24:21 -04:00
{% from "components/radios.html" import radios %}
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
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 %}
Create an API key
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
{% 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_keys', 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 %}
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
{% block maincolumn_content %}
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('Create an API key') }}
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
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% call form_wrapper() %}
Update CreateKeyForm to new fields Changes its StringFields to GovukTextInputFields. Includes changes to templates that use this form and associated tests.
2020-08-07 12:20:05 +01:00
{{ form.key_name }}
Tweaked a few more issues
2025-07-31 09:24:44 -04:00
<div class="margin-top-5">
{% if current_service.trial_mode %}
{{ radios(
form.key_type,
disable=['normal'],
option_hints={'normal': 'Not available because your service is in <a class="usa-link" href="/features/trial-mode">trial mode</a>'|safe}
) }}
{% else %}
{{ radios(form.key_type) }}
{% endif %}
</div>
Review usage of secondary/back links This commit examines all the pages that use the page footer component, and determines whether they should have a back button, a secondary link, both or neither.
2016-02-05 10:24:43 +00:00
{{ page_footer('Continue') }}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% endcall %}
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
{% endblock %}
Reference in New Issue Copy Permalink