app/templates/views/service-settings/set-inbound-number.html

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

{% block service_page_title %}
  Set inbound number
{% endblock %}

{% block maincolumn_content %}
    {{ page_header(
      'Set inbound number',
      back_link=url_for('.service_settings', service_id=current_service.id)
    ) }}
    {% if current_service.has_inbound_number %}
    <p> This service already has an inbound number </p>
    {% elif no_available_numbers %}
    <p> No available inbound numbers </p>
    {% else %}
    {% call form_wrapper() %}
	    {{ radios(form.inbound_number) }}
	    {{ page_footer('Save') }}
  	{% endcall %}
	{% endif %}

{% endblock %}
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`{% extends "withnav_template.html" %}`
			`{% from "components/textbox.html" import textbox %}`
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 %}`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`{% from "components/page-footer.html" import page_footer %}`
			`{% from "components/radios.html" import radios%}`
Fix page with missing import and added unit test. 2018-10-02 13:44:55 +01:00			`{% from "components/form.html" import form_wrapper %}`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00
			`{% block service_page_title %}`
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			`Set inbound number`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`{% endblock %}`

			`{% block maincolumn_content %}`
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_header(`
			`'Set inbound number',`
			`back_link=url_for('.service_settings', service_id=current_service.id)`
			`) }}`
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods 2018-10-26 17:31:49 +01:00			`{% if current_service.has_inbound_number %}`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`<p> This service already has an inbound number </p>`
			`{% elif no_available_numbers %}`
			`<p> No available inbound numbers </p>`
			`{% else %}`
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() %}`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`{{ radios(form.inbound_number) }}`
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 %}`
Added Multiple SMS sender functionality 2017-10-24 15:37:44 +01:00			`{% endif %}`

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			`{% endblock %}`