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 %}

{% block page_title %}
  Add a new API key – GOV.UK Notify
{% endblock %}

{% block maincolumn_content %}

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

  <form method="post">
    {{ radios(form.key_type) }}
    {{ textbox(form.key_name, label='Name for this key') }}
    {{ page_footer('Continue') }}
  </form>

{% 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 %}
-												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 page_title %}
-												Make page titles consistent

This commit modifies the HTML `<title>` tags for all the pages. It makes two
main changes:
- make the title tag match the `<h1>` of the page, for better or worse
- put the service name after the page title, seperated by an en dash, as per
  GOV.UK

											
										
										
											2016-02-08 09:23:51 +00:00
+								  Add a new API key – GOV.UK Notify
-												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>
 								  <form method="post">
-												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
+								    {{ radios(form.key_type) }}
 								    {{ textbox(form.key_name, label='Name for this key') }}
-												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') }}
-												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
+								  </form>
 								{% endblock %}