app/templates/views/api/keys/create.html

{% extends "withnav_template.html" %}
{% from "components/page-footer.html" import page_footer %}
{% from "components/textbox.html" import textbox %}
{% from "components/radios.html" import radios %}
{% from "components/banner.html" import banner_wrapper %}
{% from "components/form.html" import form_wrapper %}

{% block service_page_title %}
  Create an API key
{% endblock %}

{% block maincolumn_content %}

  <h1 class="heading-large">
    Create an API key
  </h1>

  {% call form_wrapper() %}
    {{ textbox(form.key_name, label='Name for this key') }}
    {{ radios(form.key_type, disable=disabled_options, option_hints=option_hints) }}
    {{ page_footer('Continue') }}
  {% endcall %}

{% 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			`{% extends "withnav_template.html" %}`
			`{% from "components/page-footer.html" import page_footer %}`
			`{% from "components/textbox.html" import textbox %}`
Add radio buttons for choosing the API key type Best-guess wording for what the labels and question should be. Adds a macro for rendering radio buttons from a WTForms field. 2016-06-29 17:10:49 +01:00			`{% from "components/radios.html" import radios %}`
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 %}`
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 %}`

			`{% block maincolumn_content %}`

Make headings `.heading-large` instead of `.heading-xlarge` 2016-02-02 14:05:45 +00:00			`<h1 class="heading-large">`
Rename ‘Add a new API key’ page ‘Create’ matches the text of the button on the previous page. 2016-06-29 17:09:55 +01:00			`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			`</h1>`

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() %}`
Add radio buttons for choosing the API key type Best-guess wording for what the labels and question should be. Adds a macro for rendering radio buttons from a WTForms field. 2016-06-29 17:10:49 +01:00			`{{ textbox(form.key_name, label='Name for this key') }}`
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			`{{ radios(form.key_type, disable=disabled_options, option_hints=option_hints) }}`
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 %}`