app/templates/views/service-settings/name.html


{% extends "withnav_template.html" %}
{% from "components/page-header.html" import page_header %}
{% from "components/page-footer.html" import page_footer %}
{% from "components/form.html" import form_wrapper %}
{% from "components/back-link/macro.njk" import govukBackLink %}

{% block service_page_title %}
  Change your service name
{% endblock %}


{% block backLink %}
  {{ govukBackLink({ "href": url_for('main.service_settings', service_id=current_service.id) }) }}
{% endblock %}

{% block maincolumn_content %}

  {{ page_header('Change your service name') }}

  <div class="form-group">
    {% if current_service.prefix_sms %}
      <p class="govuk-body">Users will see your service name:</p>
      <ul class="list-bullet">
        <li>at the start of every text message</li>
        <li>as your email sender name</li>
      </ul>
    {% else %}
      <p class="govuk-body">Users will see your service name as your email sender name.</p>
    {% endif %}
  </div>

  {% call form_wrapper() %}
    {{ form.name }}
    {{ page_footer('Save') }}
  {% endcall %}

{% endblock %}
add template folder form 2018-11-01 16:02:43 +00:00
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +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 %}`
Rename `submit_form` component to `page_footer` Submit form was - a confusing name in itself - not descriptive, because it also has an optional ‘back’ link This commit also puts this component in as many pages as possible, stripping out any hard-coded buttons and links. It replaces any usage of buttons for ‘back’, because these are links, not buttons (ie they don’t change any data). 2016-01-07 20:11:22 +00:00			`{% from "components/page-footer.html" import page_footer %}`
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 %}`
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			`{% from "components/back-link/macro.njk" import govukBackLink %}`
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +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 %}`
			`Change your service name`
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +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 %}`
			`{{ govukBackLink({ "href": url_for('main.service_settings', service_id=current_service.id) }) }}`
			`{% endblock %}`

Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +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('Change your service name') }}`
Make wording on 2nd-level pages match prev. commit 2016-01-08 17:17:34 +00:00
Remove 3/4 width column on settings pages The mesaure on these pages was too short, making them awkward to read. Also varies the size of text boxes to make them appropriate to the expected size of content that they will contain. 2016-08-24 15:31:49 +01:00			`<div class="form-group">`
Correct description of how service name appears This has changed since we made prefixing text messages its own setting. 2018-01-11 17:33:04 +00:00			`{% if current_service.prefix_sms %}`
Don’t allow paragraphs without class attribute All paragraphs should have class="govuk-body", or be otherwise custom-styled. This commit adds some extra checks to our test fixture that looks for paragraphs that don’t have any styling. Our test coverage is pretty good, so this should check almost all pages, and prevent regressions. I’ve done this in such a way that it can be extended for other elements (e.g. links) in the future. 2020-05-29 17:11:01 +01:00			`<p class="govuk-body">Users will see your service name:</p>`
Correct description of how service name appears This has changed since we made prefixing text messages its own setting. 2018-01-11 17:33:04 +00:00			`<ul class="list-bullet">`
Remove example Removed `eg ‘{service name}: This is an example message’ – the content is already self explanatory 2019-07-16 16:05:42 +01:00			`<li>at the start of every text message</li>`
Correct description of how service name appears This has changed since we made prefixing text messages its own setting. 2018-01-11 17:33:04 +00:00			`<li>as your email sender name</li>`
			`</ul>`
			`{% else %}`
Don’t allow paragraphs without class attribute All paragraphs should have class="govuk-body", or be otherwise custom-styled. This commit adds some extra checks to our test fixture that looks for paragraphs that don’t have any styling. Our test coverage is pretty good, so this should check almost all pages, and prevent regressions. I’ve done this in such a way that it can be extended for other elements (e.g. links) in the future. 2020-05-29 17:11:01 +01:00			`<p class="govuk-body">Users will see your service name as your email sender name.</p>`
Correct description of how service name appears This has changed since we made prefixing text messages its own setting. 2018-01-11 17:33:04 +00:00			`{% endif %}`
Add confirm loop For pages where - we want you to be sure that you want to do what you’re about to do - we want to be sure it’s you trying to do the thing This adds a page that asks the user to confirm their password. 2016-01-07 16:24:43 +00:00			`</div>`
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +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() %}`
Use GovukTextInputField in RenameServiceForm Includes changes to templates that use this form and associated tests. 2020-07-14 16:51:11 +01:00			`{{ form.name }}`
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			`{{ page_footer('Save') }}`
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 %}`
Remove 3/4 width column on settings pages The mesaure on these pages was too short, making them awkward to read. Also varies the size of text boxes to make them appropriate to the expected size of content that they will contain. 2016-08-24 15:31:49 +01:00
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions. 2016-01-07 12:29:56 +00:00			`{% endblock %}`