darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-15 15:28:50 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
d2784d0d8a823d0d9a6dcafe9a57f3e7876ad363
notifications-admin/app/templates/views/service-settings/email_reply_to.html

83 lines
3.1 KiB
HTML
Raw Normal View History

Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
{% extends "withnav_template.html" %}
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
{% from "components/api-key.html" import api_key %}
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 %}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{% from "components/table.html" import row_group, row, text_field, edit_field, field, boolean_field, list_table with context %}
Replace straightforward buttons and links styled like buttons This replaces the buttons that aren't part of a macro and that we don't need to write additional styles for with their govuk-frontend equivalent. There were some links that were styled to look like buttons, so these have also been replaced with the new govuk-frontend macro. There was one button on the `choose-account.html` template that was in a section of code that was never reached - this has been deleted.
2020-01-30 14:01:13 +00:00
{% from "components/button/macro.njk" import govukButton %}
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 %}
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
{% block service_page_title %}
Change 'email reply-to' to 'reply-to email'
2019-07-09 16:32:10 +01:00
Reply-to email addresses
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +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 %}
{{ govukBackLink({ "href": url_for('main.service_settings', service_id=current_service.id) }) }}
{% endblock %}
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +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('Reply-to email addresses') }}
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
<div class="user-list">
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 not current_service.email_reply_to_addresses %}
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
<div class="user-list-item">
Fix email reply-to addresses page
2020-08-26 21:21:12 +01:00
<p class="govuk-body user-list-item-blank hint">You have not added any reply-to email addresses yet</p>
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
</div>
{% endif %}
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
{% for item in current_service.email_reply_to_addresses %}
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
<div class="user-list-item">
Fix email reply-to addresses page
2020-08-26 21:21:12 +01:00
<div class="govuk-grid-row">
<div class="govuk-grid-column-three-quarters">
<h2 class="user-list-item-heading">
<span class="heading-small">{{ item.email_address }}</span>&ensp;<span class="hint">
{%- if item.is_default -%}
(default)
{% endif %}
</span>
</h2>
</div>
<div class="govuk-grid-column-one-quarter">
{% if current_user.has_permissions('manage_service') %}
Add descriptive links to /service-settings/email-reply-to page The links had no descriptive text, so all read 'Change'. This adds hidden text specific to the item they relate to.
2021-02-23 14:12:10 +00:00
<a class="govuk-link govuk-link--no-visited-state user-list-edit-link"href="{{ url_for('.service_edit_email_reply_to', service_id =current_service.id, reply_to_email_id = item.id) }}">
Change<span class="govuk-visually-hidden"> {{ item.email_address }}</span>
</a>
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
{% endif %}
Fix email reply-to addresses page
2020-08-26 21:21:12 +01:00
</div>
</div>
<div class="govuk-grid-row">
<div class="govuk-grid-column-full">
{% if current_service.count_email_reply_to_addresses > 1 %}
{{ api_key(item.id, name=item.email_address, thing="ID") }}
{% endif %}
</div>
</div>
Add email reply address to ID to the page The first users of multiple email reply to addresses will be using the API. This means that the need to be able to specify the ID of the reply to address they want. We chose to implement it like this instead of by passing the address in directly because that means deploying code. For some teams deploying code can take weeks, and we’d like to let teams have the flexibility to make changes faster than this. Same as for templates, you shouldn’t have to go to the _edit_ page in order to get the ID. This means listing them on the page where you see all the reply to addresses. Listing the IDs like this means that it’s not really a table any more, because the information isn’t organised in columns. So I think it makes sense to reuse the pattern from the manage team page, which has a similar relationship between the information.
2017-09-26 15:51:36 +01:00
</div>
{% endfor %}
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
</div>
Replace `grid-row` with `govuk-grid-row` Replaced all instances of `grid-row` in the HTML and JavaScript with `govuk-grid-row`, which is the new GOV.UK Frontend class.
2020-02-19 11:57:15 +00:00
<div class="govuk-grid-row">
Replace the `.column-...` classes in _grids.scss We had 7 classes in _grids.scss named `.column-...` which were being used to give a certain column width. These worked by using `@include grid column()`, which is now deprecated. `.column-whole` and `.column-three-quarters` can be removed and replaced with `govuk-grid-column-full` and `govuk-grid-column-three-quarters` respectively. The other column classes don't have a direct replacment in GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width` SASS map in `extensions.scss` to add in extra widths, then use this with the `govuk-grid-column` mixin to create new classes in for our custom widths in `_grids.scss`
2020-02-20 16:55:56 +00:00
<div class="govuk-grid-column-full">
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
{% if current_user.has_permissions('manage_service') %}
<div class="js-stick-at-bottom-when-scrolling">
Replace straightforward buttons and links styled like buttons This replaces the buttons that aren't part of a macro and that we don't need to write additional styles for with their govuk-frontend equivalent. There were some links that were styled to look like buttons, so these have also been replaced with the new govuk-frontend macro. There was one button on the `choose-account.html` template that was in a section of code that was never reached - this has been deleted.
2020-01-30 14:01:13 +00:00
{{ govukButton({
"element": "a",
"text": "Add reply-to email address",
"href": url_for('.service_add_email_reply_to', service_id=current_service.id),
}) }}
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
</div>
{% endif %}
</div>
Replace the `.column-...` classes in _grids.scss We had 7 classes in _grids.scss named `.column-...` which were being used to give a certain column width. These worked by using `@include grid column()`, which is now deprecated. `.column-whole` and `.column-three-quarters` can be removed and replaced with `govuk-grid-column-full` and `govuk-grid-column-three-quarters` respectively. The other column classes don't have a direct replacment in GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width` SASS map in `extensions.scss` to add in extra widths, then use this with the `govuk-grid-column` mixin to create new classes in for our custom widths in `_grids.scss`
2020-02-20 16:55:56 +00:00
<div class="govuk-grid-column-five-sixths">
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">
Updated reply-to address content Updated reply-to address content to better explain why users need to add a reply-to address.
2018-11-29 11:26:19 +00:00
You need to add at least one reply-to address so recipients can reply to your messages.
Grey out None when email reply to not set This is consistent with how we differentiate other ‘unset’ values on the settings page.
2017-09-26 15:08:21 +01:00
</p>
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">
Updated reply-to address content Updated reply-to address content to better explain why users need to add a reply-to address.
2018-11-29 11:26:19 +00:00
Emails with a reply-to address:
Grey out None when email reply to not set This is consistent with how we differentiate other ‘unset’ values on the settings page.
2017-09-26 15:08:21 +01:00
</p>
Updated reply-to address content Updated reply-to address content to better explain why users need to add a reply-to address.
2018-11-29 11:26:19 +00:00
<ul class="list list-bullet">
Remove go-live requirement content
2018-12-03 13:55:14 +00:00
<li>are less likely to be labelled as spam</li>
<li>appear more trustworthy</li>
</ul>
Grey out None when email reply to not set This is consistent with how we differentiate other ‘unset’ values on the settings page.
2017-09-26 15:08:21 +01:00
</div>
</div>
Make ‘Add new’ buttons sticky on more pages For consistency with the template management page.
2019-02-01 12:36:03 +00:00
Grey out None when email reply to not set This is consistent with how we differentiate other ‘unset’ values on the settings page.
2017-09-26 15:08:21 +01:00
{% endblock %}
Reference in New Issue Copy Permalink