app/templates/views/service-settings/data-retention/edit.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/components/back-link/macro.njk" import usaBackLink %}

{% block service_page_title %}
  Set data retention
{% endblock %}

{% block backLink %}
  {{ usaBackLink({ "href": url_for('.edit_data_retention', service_id=current_service.id, data_retention_id=data_retention_id) }) }}
{% endblock %}

{% block maincolumn_content %}

    {{ page_header('Set data retention') }}
    {% call form_wrapper() %}
      {{ notification_type | capitalize}}
      {{  form.days_of_retention }}
      {{ page_footer('Save') }}
    {% endcall %}

{% endblock %}
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01: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 %}`
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01: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 %}`
Committing before merge 2023-08-30 11:07:38 -04:00			`{% from "components/components/back-link/macro.njk" import usaBackLink %}`
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01:00
			`{% block service_page_title %}`
Stop using `platform_admin_client` fixture We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object For most tests of a platform admin view we used `platform_admin_client` instead. This is not as good because it returns a raw `Response` object and doesn’t do the additional checks. This commit converts all the tests using `platform_admin_client` to: use new `client_request` and log in as `platform_admin_user` before making any requests. This is also nice because it makes any test easy to parametrize with additional users, for example to test differences in behaviour dependant on being platform admin or not. 2021-12-30 16:13:49 +00:00			`Set data retention`
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01: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('.edit_data_retention', service_id=current_service.id, data_retention_id=data_retention_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 %}`

Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01: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('Set data retention') }}`
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() %}`
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01:00			`{{ notification_type \| capitalize}}`
Convert IntegerFields to GovukIntegerFields Changes those fields in the following forms: - FreeSMSAllowance - ProviderForm - ProviderRatioForm - ServiceDataRetentionEditForm Includes changes to templates that use this form and associated tests. 2020-08-07 10:31:09 +01:00			`{{ form.days_of_retention }}`
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 %}`
Adding views to view, add and edit service data retention policies. Only visible to a platform admin. A service can have a custom number of days to retain the notification data for each notification type. 2018-07-17 14:39:04 +01: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			`{% endblock %}`