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

373 lines
14 KiB
HTML
Raw Normal View History

Added main nav to logged in pages
2015-12-14 16:53:07 +00:00
{% extends "withnav_template.html" %}
Add a new banner for telling you about trial mode We’ve found in research that developers have no idea they’re in trial mode until they hit an error. And even then they don’t really know what trial mode means. So this commit: - adds a message to the API integration page about trial mode - puts it in a really yellow banner to draw attention to it - adds the same banner to the settings page
2016-09-20 12:12:58 +01:00
{% from "components/banner.html" import banner_wrapper %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% from "components/table.html" import mapping_table, row, settings_row, text_field, optional_text_field, edit_field, field, boolean_field with context %}
Added the shell service settings page [ci skip]
2015-11-30 16:16:58 +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 %}
Settings
Added the shell service settings page [ci skip]
2015-11-30 16:16:58 +00:00
{% endblock %}
Added main nav to logged in pages
2015-12-14 16:53:07 +00:00
{% block maincolumn_content %}
Added the shell service settings page [ci skip]
2015-11-30 16:16:58 +00:00
Remove the verbs from the navigation Because ‘Send text messages’ isn’t very helpful if you’re looking to edit a template. It also helps front-load the navigation, ie ‘Team’ is the first word, rather than the more generic ‘Manage’.
2016-04-01 10:42:23 +01:00
<h1 class="heading-large">Settings</h1>
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
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
<div class="bottom-gutter-3-2 dashboard-table body-copy-table">
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% call mapping_table(
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
caption='General',
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=False
) %}
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% call row() %}
add letter_contact_block edit fields no actual template functionality yet - just the ability for services that have letters enabled to edit a 10 line block that will go on the top right hand side of their letters with contact information
2017-03-02 15:56:28 +00:00
{{ text_field('Service name') }}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{{ text_field(current_service.name) }}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{{ edit_field(
'Change',
url_for('.service_name_change', service_id=current_service.id),
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
permissions=['manage_service']
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
)
}}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% endcall %}
add letter_contact_block edit fields no actual template functionality yet - just the ability for services that have letters enabled to edit a 10 line block that will go on the top right hand side of their letters with contact information
2017-03-02 15:56:28 +00:00
Invite users to choose how team members sign in Email auth is a new feature that currently we’ve only given to teams who have contact us with a problem. At the moment, we’re aware of all the teams that are sharing phone numbers when they sign in. We think that in the future there will be other teams who encounter this problem. So we should let them know that they should contact us if they are having the problem. At the moment we want to talk to teams before giving them access to the feature, so that we’re confident it’s only going to teams from whom it’s more secure than using a text message code.
2017-11-23 09:59:34 +00:00
{% call row() %}
{{ text_field('Sign-in method') }}
{{ text_field(
'Email link or text message code'
if 'email_auth' in current_service.permissions
else 'Text message code'
) }}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{{ edit_field(
'Change',
url_for('.service_set_auth_type',
service_id=current_service.id),
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
permissions=['manage_service']
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
)
}}
Invite users to choose how team members sign in Email auth is a new feature that currently we’ve only given to teams who have contact us with a problem. At the moment, we’re aware of all the teams that are sharing phone numbers when they sign in. We think that in the future there will be other teams who encounter this problem. So we should let them know that they should contact us if they are having the problem. At the moment we want to talk to teams before giving them access to the feature, so that we’re confident it’s only going to teams from whom it’s more secure than using a text message code.
2017-11-23 09:59:34 +00:00
{% endcall %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='upload_document') %}
Allow service contact details to be phone number, email or url Service contact details are needed if the upload document permission is enabled - this used to be a link but services can now choose to use a link, email address or phone number. The form to add or change service contact details now gives these options and validates the data according to the type of contact details provided. When validating phone numbers we can't use the existing validation because we want to allow landlines too, so there is a basic check that the phone number is the right length and doesn't include certain characters.
2018-08-09 11:59:05 +01:00
{{ text_field('Contact details') }}
Truncate contact link text on settings page The contact link on the settings page should be truncated instead of the text being wrapped and overflowing on to multiple lines. This adds in an option to the text_field macro to truncate long text fields. This setting has been used to truncate the API callback URLs too on the services/<service_id>/api/callbacks page.
2018-06-07 10:55:48 +01:00
{{ text_field(current_service.contact_link, truncate=true) }}
Display contact link on service settings page The contact link for the service now gets displayed on the service settings page if the service has the 'upload_document' permission. There are no changes to the appearance of the service settings page if a service does not have the 'upload_document' permission.
2018-06-05 15:28:22 +01:00
{{ edit_field(
'Change',
url_for('.service_set_contact_link',
service_id=current_service.id),
permissions=['manage_service']
)
}}
{% endcall %}
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
{% endcall %}
{% call mapping_table(
caption='Email',
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=True
) %}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% call row() %}
Allow sending emails to be disabled Platform admins can now disable sending of emails for a service. If sending emails is disabled, this will also hide the option to change the Email reply to address.
2017-06-26 15:22:06 +01:00
{{ text_field('Send emails') }}
{{ boolean_field('email' in current_service.permissions) }}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{{ edit_field(
Let users switch channels on and off by themselves We let people do this for letters already. We should let them do it for emails and texts too, rather than have to email us.
2019-01-29 14:51:31 +00:00
'Change',
url_for(
'.service_set_channel',
channel='email',
service_id=current_service.id
),
permissions=['manage_service']
)}}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% endcall %}
add letter_contact_block edit fields no actual template functionality yet - just the ability for services that have letters enabled to edit a 10 line block that will go on the top right hand side of their letters with contact information
2017-03-02 15:56:28 +00:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='email') %}
'Email reply-to addresses' updated Updated 'reply-to address' to include a hyphen
2018-08-20 16:48:21 +01:00
{{ text_field('Email reply-to addresses') }}
Grey-out ‘Not set’ for email reply-to address The `default_reply_to_email_address` variable was not set anywhere so the conditional was having no effect.
2019-01-29 16:40:44 +00:00
{% call field(status='default' if current_service.count_email_reply_to_addresses == 0 else '') %}
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
{{ current_service.default_email_reply_to_address or 'Not set' }}
{% if current_service.count_email_reply_to_addresses > 1 %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
<div class="hint">
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
{{ '…and %d more' | format(current_service.count_email_reply_to_addresses - 1) }}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
</div>
{% endif %}
Add page where users can say they want branding At the moment branding is an undocumented feature. We get a bunch of support tickets from teams asking its possible. This commit: - lets people know it’s possible, and what the options are - is the first step towards making this process as self-service as possible In some cases we will be able to infer a user’s organisation from there email address, and Google image search their logo. So the experience for them is that they press a button and government just sorts it out for you (also known as "the dream"). In other cases we will have to get back to people asking for a copy of their logo, or to find out about their service, but this is what we have to do at the moment anyway.
2018-05-18 14:05:48 +01:00
{% endcall %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{{ edit_field(
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
'Manage' if current_service.count_email_reply_to_addresses else 'Change',
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
url_for('.service_email_reply_to',
service_id=current_service.id),
permissions=['manage_service','manage_api_keys']
)
}}
{% endcall %}
Add page where users can say they want branding At the moment branding is an undocumented feature. We get a bunch of support tickets from teams asking its possible. This commit: - lets people know it’s possible, and what the options are - is the first step towards making this process as self-service as possible In some cases we will be able to infer a user’s organisation from there email address, and Google image search their logo. So the experience for them is that they press a button and government just sorts it out for you (also known as "the dream"). In other cases we will have to get back to people asking for a copy of their logo, or to find out about their service, but this is what we have to do at the moment anyway.
2018-05-18 14:05:48 +01:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='email') %}
{{ text_field('Email branding') }}
Say what the current email branding is We keep getting people requesting branding when they already have the branding they want set. Seems like they don’t realise we’re doing it automatically. This might help.
2019-04-02 09:30:01 +01:00
{{ text_field('Your branding<br> ({})'.format(current_service.email_branding_name)|safe if current_service.email_branding else current_service.email_branding_name) }}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{{ edit_field(
'Change',
url_for('.branding_request', service_id=current_service.id),
Hide email branding change if not manage service If you have the API keys permission you can see the settings page. But you can’t change or request stuff, like email branding. So we shouldn’t show the link that suggests you can.
2018-08-06 11:25:19 +01:00
permissions=['manage_service'],
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
)}}
{% endcall %}
Allow sending emails to be disabled Platform admins can now disable sending of emails for a service. If sending emails is disabled, this will also hide the option to change the Email reply to address.
2017-06-26 15:22:06 +01:00
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
{% endcall %}
{% call mapping_table(
caption='Text messages',
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=True
) %}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% call row() %}
Allow sending sms to be disabled Platform admins can now disable sending sms for a service. If sending sms is disabled, this will also hide all the other sms options in the Settings table.
2017-06-26 16:22:48 +01:00
{{ text_field('Send text messages') }}
{{ boolean_field('sms' in current_service.permissions) }}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{{ edit_field(
Let users switch channels on and off by themselves We let people do this for letters already. We should let them do it for emails and texts too, rather than have to email us.
2019-01-29 14:51:31 +00:00
'Change',
url_for(
'.service_set_channel',
service_id=current_service.id,
channel='sms'
),
permissions=['manage_service']
)}}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
{% endcall %}
Tell users that letters are coming Users might be interested in letters. And when they’re fully available, users will probably be able to control whether letters are on/off for their service. Until that point, the only way of getting the feature is to ask us. So let’s make an in-the-meantime page that directs them to ask us, from the place where they’d be able to do it themselves. Wording TBC.
2017-05-02 11:03:10 +01:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='sms') %}
{{ text_field('Text message sender') }}
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
{% call field(status='default' if current_service.default_sms_sender == "None" else '') %}
{{ current_service.default_sms_sender | string | nl2br | safe if current_service.default_sms_sender else 'None'}}
{% if current_service.count_sms_senders > 1 %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
<div class="hint">
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
{{ '…and %d more' | format(current_service.count_sms_senders - 1) }}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
</div>
{% endif %}
Allow updates to SMS prefixing setting We’re extracting this from being determined based on what the sender name is to its own setting. This commit will let users set it independently. Until the explicitly set it, it will still be determined based on whether their default sender name matches the default for the platform.
2017-11-03 15:01:41 +00:00
{% endcall %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{{ edit_field(
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
'Manage' if current_service.count_sms_senders > 1 else 'Change',
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
url_for('.service_sms_senders',
service_id=current_service.id),
permissions=['manage_service','manage_api_keys']
)
}}
{% endcall %}
Allow updates to SMS prefixing setting We’re extracting this from being determined based on what the sender name is to its own setting. This commit will let users set it independently. Until the explicitly set it, it will still be determined based on whether their default sender name matches the default for the platform.
2017-11-03 15:01:41 +00:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='sms') %}
{{ text_field('Text messages start with service name') }}
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
{{ boolean_field(current_service.prefix_sms) }}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{{ edit_field(
'Change',
url_for('.service_set_sms_prefix',
service_id=current_service.id),
permissions=['manage_service']
)
}}
{% endcall %}
Allow sending sms to be disabled Platform admins can now disable sending sms for a service. If sending sms is disabled, this will also hide all the other sms options in the Settings table.
2017-06-26 16:22:48 +01:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='sms') %}
{{ text_field('International text messages') }}
{{ boolean_field('international_sms' in current_service.permissions) }}
{{ edit_field(
'Change',
url_for('.service_set_international_sms',
service_id=current_service.id),
permissions=['manage_service']
)
}}
{% endcall %}
Allow sending sms to be disabled Platform admins can now disable sending sms for a service. If sending sms is disabled, this will also hide all the other sms options in the Settings table.
2017-06-26 16:22:48 +01:00
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='sms') %}
{{ text_field('Receive text messages') }}
{{ boolean_field('inbound_sms' in current_service.permissions) }}
{{ edit_field(
'Change',
url_for('.service_set_inbound_sms',
service_id=current_service.id),
permissions=['manage_service']
)
}}
{% endcall %}
Refactor inbound api html and processing
2017-06-20 13:24:01 +01:00
Split settings page into multiple sections There are quite a few more options that there used to be in the settings page. This means it’s hard to find the thing you want to change. Grouping options is a common way of making things easier to find. Grouping by channel (text, email, letter) is something we do elsewhere that seems to work pretty well.
2017-07-12 15:50:11 +01:00
{% endcall %}
{% call mapping_table(
caption='Letters',
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=True
) %}
Tell users that letters are coming Users might be interested in letters. And when they’re fully available, users will probably be able to control whether letters are on/off for their service. Until that point, the only way of getting the feature is to ask us. So let’s make an in-the-meantime page that directs them to ask us, from the place where they’d be able to do it themselves. Wording TBC.
2017-05-02 11:03:10 +01:00
{% call row() %}
Rename letters on/off option to send letters For consistency with ‘send text messages’/‘send emails’.
2017-07-12 16:02:33 +01:00
{{ text_field('Send letters') }}
Refactored code for new service permissions
2017-06-23 13:35:08 +01:00
{{ boolean_field('letter' in current_service.permissions) }}
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{{ edit_field(
Let users switch channels on and off by themselves We let people do this for letters already. We should let them do it for emails and texts too, rather than have to email us.
2019-01-29 14:51:31 +00:00
'Change',
url_for(
'.service_set_channel',
channel='letter',
service_id=current_service.id
),
permissions=['manage_service']
)}}
Tell users that letters are coming Users might be interested in letters. And when they’re fully available, users will probably be able to control whether letters are on/off for their service. Until that point, the only way of getting the feature is to ask us. So let’s make an in-the-meantime page that directs them to ask us, from the place where they’d be able to do it themselves. Wording TBC.
2017-05-02 11:03:10 +01:00
{% endcall %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{% call settings_row(if_has_permission='letter') %}
{{ text_field('Sender addresses') }}
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
{% call field(status='default' if current_service.default_letter_contact_block == None else '') %}
{{ current_service.default_letter_contact_block | string | nl2br | safe if current_service.default_letter_contact_block else 'Not set'}}
{% if current_service.count_letter_contact_details > 1 %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
<div class="hint">
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
{{ '…and %d more' | format(current_service.count_letter_contact_details - 1) }}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
</div>
{% endif %}
add letter_contact_block edit fields no actual template functionality yet - just the ability for services that have letters enabled to edit a 10 line block that will go on the top right hand side of their letters with contact information
2017-03-02 15:56:28 +00:00
{% endcall %}
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
{{ edit_field(
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
'Manage' if current_service.count_letter_contact_details else 'Change',
Add Jinja macro for a row on the settings page Often we show/hide these rows based on what permissions a service has. This commits refactors that check into a reusable macro, rather than having to write the same `if` statements all the time.
2018-07-09 16:58:04 +01:00
url_for('.service_letter_contact_details',
service_id=current_service.id),
permissions=['manage_service','manage_api_keys']
)
}}
{% endcall %}
[WIP] Page and form to persist the inbound api data for a service.
2017-06-15 16:20:07 +01:00
Tell people they can have their logo on letters At the moment there’s nothing in Notify that says the logo on letter templates can be changed from ‘HM Government’. While some people guess that it’s possible, or are motivated enough to enquire, others might be assuming that the branding can’t be changed (and thus deciding Notify letters aren’t for them). In the future we should make this process slicker (eg with a file upload) but the easiest, quickest improvement to make for now is: - let people know that the branding can be changed - direct them to support if they do want to change it
2018-08-21 09:23:32 +01:00
{% call settings_row(if_has_permission='letter') %}
{{ text_field('Letter branding') }}
letter branding text fields should be optional
2019-02-05 17:21:09 +00:00
{{ optional_text_field(current_service.letter_branding.name) }}
Tell people they can have their logo on letters At the moment there’s nothing in Notify that says the logo on letter templates can be changed from ‘HM Government’. While some people guess that it’s possible, or are motivated enough to enquire, others might be assuming that the branding can’t be changed (and thus deciding Notify letters aren’t for them). In the future we should make this process slicker (eg with a file upload) but the easiest, quickest improvement to make for now is: - let people know that the branding can be changed - direct them to support if they do want to change it
2018-08-21 09:23:32 +01:00
{{ edit_field(
'Change',
url_for('.request_letter_branding', service_id=current_service.id),
permissions=['manage_service']
)}}
{% endcall %}
Make settings page a table not a browse list There’s no way of seeing what the current settings are for a service without individually going to the pages where you can change them. This commit replaces the list of settings with a table. The table plays back the current value for each setting. This is a pattern that has worked well on various services[1] as well as on our own user profile page. 1. https://designpatterns.hackpad.com/Check-your-answers-page-2DSpTH9J0wU
2016-08-22 11:43:35 +01:00
{% endcall %}
Remove ‘suspend API keys’ This was an early reckon feature. There were a few of problems with it: - it worked on the service, not just on the API keys as described - it was back to front, ‘suspending’ a service set `active` to `True`, reactivating it set `active` to `False` - no part of the API actually respected the `active` flag on a service The same intent can be acheived by either: - revoking an API key - having a platform admin put your service back into trial mode So this commit removes the link and the code behind it.
2016-08-22 14:39:57 +01:00
</div>
Added the shell service settings page [ci skip]
2015-11-30 16:16:58 +00:00
Don’t have service model inherit from `dict` Inheriting from `dict` has some unexpected side effects that don’t happen with plain object. The one we want to avoid right now is that a dict doesn’t seem to implement `__dict__` in a normal way, which is required by `werkzeug.utils.cached_property`.
2018-10-26 11:19:50 +01:00
{% if current_service.trial_mode %}
Remove banner for trial mode message The yellow banner didn’t make this information much more noticeable, and it made some people miss the request to go live link because it wasn’t blue. This commit brings the design back to where it was as of this PR: https://github.com/alphagov/notifications-admin/pull/904
2016-11-04 09:50:11 +00:00
<h2 class="heading-medium">Your service is in trial mode</h2>
<ul class='list list-bullet'>
<li>you can only send messages to yourself</li>
<li>you can add people to your team, then you can send messages to them too</li>
Make message limit dynamic Because we sometimes bump it in exceptional circumstances.
2018-12-17 15:37:42 +00:00
<li>you can only send {{ current_service.message_limit }} messages per day</li>
Remove banner for trial mode message The yellow banner didn’t make this information much more noticeable, and it made some people miss the request to go live link because it wasn’t blue. This commit brings the design back to where it was as of this PR: https://github.com/alphagov/notifications-admin/pull/904
2016-11-04 09:50:11 +00:00
</ul>
<p>
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
{% if current_user.has_permissions('manage_service') %}
Hide ‘request to go live’ from API only users Users who have the ‘manage API keys’ permission can see the settings page. But they don’t have permission to request to go live. At the moment they can still see the link, though clicking it gives them a 403 error. This commit changes it so that they can’t see the link, and tells them who they should speak to about going live (their manager).
2018-02-22 13:13:57 +00:00
To remove these restrictions
<a href="{{ url_for('.request_to_go_live', service_id=current_service.id) }}">request to go live</a>.
{% else %}
Your service manager can ask to have these restrictions removed.
{% endif %}
</p>
Tell users when their service is live Seen it a few times in research where people are like “so it’s live now … I think. Is it?” Let’s tell them exactly what’s happened. Also a chance to get @minglis’ idea about showing the daily limit.
2016-11-04 10:38:37 +00:00
{% else %}
<h2 class="heading-medium">Your service is live</h2>
<p>
You can send up to
{{ "{:,}".format(current_service.message_limit) }} messages
per day.
</p>
<p>
Problems or comments?
Add a support index page Our support process is about to get more fully fledged so we’ll need an index page to route people properly. We reckon that users will also want to know what the support process is, so let’s explain it on this page.
2016-12-12 11:18:25 +00:00
<a href="{{ url_for('main.support') }}">Give feedback</a>.
Tell users when their service is live Seen it a few times in research where people are like “so it’s live now … I think. Is it?” Let’s tell them exactly what’s happened. Also a chance to get @minglis’ idea about showing the daily limit.
2016-11-04 10:38:37 +00:00
</p>
Remove banner for trial mode message The yellow banner didn’t make this information much more noticeable, and it made some people miss the request to go live link because it wasn’t blue. This commit brings the design back to where it was as of this PR: https://github.com/alphagov/notifications-admin/pull/904
2016-11-04 09:50:11 +00:00
{% endif %}
dont use has_permissions to check for platform admins platform_admin is a separate concept to permissions, so by removing the checks for it from the current_user.has_permissions function, we can simplify things greatly. We already record on the user whether they're a platform admin anyway.
2018-02-27 16:45:20 +00:00
{% if current_user.platform_admin %}
Split platform admin settings into new section Makes it clearer what a normal user can change and what a platform admin can change.
2016-08-22 10:44:45 +01:00
Add spacing, balance type size
2016-08-22 20:22:47 +01:00
<h2 class="heading-medium">Platform admin settings</h2>
Make email branding settings a table So that it matches the other settings on this page
2016-08-24 09:34:14 +01:00
{% call mapping_table(
caption='Settings',
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=False
) %}
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
{% call row() %}
{{ text_field('Live')}}
{{ boolean_field(not current_service.trial_mode) }}
{{ edit_field('Change', url_for('.service_switch_live', service_id=current_service.id)) }}
{% endcall %}
Allow excluding services from live services count Adds a front end for: https://github.com/alphagov/notifications-api/pull/2417 > Sometimes we have to make a few services for what really is one > service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also > have our own test services which aren’t included in the count of live > services. We currently count these as one service by not including > them in the beta partners spreadsheet.
2019-03-25 14:46:42 +00:00
{% call row() %}
{{ text_field('Count in list of live services')}}
{{ text_field('Yes' if current_service.count_as_live else 'No') }}
{{ edit_field('Change', url_for('.service_switch_count_as_live', service_id=current_service.id)) }}
{% endcall %}
link-services-to-organisations
2018-02-12 09:26:13 +00:00
{% call row() %}
{{ text_field('Organisation')}}
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
{{ optional_text_field(current_service.organisation_name) }}
link-services-to-organisations
2018-02-12 09:26:13 +00:00
{{ edit_field('Change', url_for('.link_service_to_organisation', service_id=current_service.id)) }}
{% endcall %}
Show org type and free allowance on settings page As a platform admin it’s useful to be able to see what each service has set for these attributes.
2017-10-05 11:08:22 +01:00
{% call row() %}
{{ text_field('Organisation type')}}
Add ‘optional text’ macro This pattern of value or grey text saying `None` is common enough in our app that we should codify it into a pattern. Which this commit does.
2017-10-05 11:21:00 +01:00
{{ optional_text_field(
(current_service.organisation_type or '')|title
Show org type and free allowance on settings page As a platform admin it’s useful to be able to see what each service has set for these attributes.
2017-10-05 11:08:22 +01:00
) }}
Add page to change organisation type If a user picks the wrong thing, we should be able to override it when they go live.
2017-10-05 12:06:40 +01:00
{{ edit_field('Change', url_for('.set_organisation_type', service_id=current_service.id)) }}
Show org type and free allowance on settings page As a platform admin it’s useful to be able to see what each service has set for these attributes.
2017-10-05 11:08:22 +01:00
{% endcall %}
{% call row() %}
{{ text_field('Free text message allowance')}}
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
{{ text_field('{:,}'.format(current_service.free_sms_fragment_limit)) }}
Add page to change SMS allowance There may be exceptions to the rule, so we should have a way of overriding this manually.
2017-10-05 13:49:43 +01:00
{{ edit_field('Change', url_for('.set_free_sms_allowance', service_id=current_service.id)) }}
Show org type and free allowance on settings page As a platform admin it’s useful to be able to see what each service has set for these attributes.
2017-10-05 11:08:22 +01:00
{% endcall %}
Make email branding settings a table So that it matches the other settings on this page
2016-08-24 09:34:14 +01:00
{% call row() %}
{{ text_field('Email branding' )}}
Put current email branding in new branding request When we get a request for new branding it’s helpful to quickly see what the service’s current branding is, so we can get a better sense of why they want to change it.
2019-03-06 15:27:43 +00:00
{{ text_field(current_service.email_branding_name) }}
Change organisations to email branding
2018-02-07 10:30:49 +00:00
{{ edit_field('Change', url_for('.service_set_email_branding', service_id=current_service.id)) }}
Make email branding settings a table So that it matches the other settings on this page
2016-08-24 09:34:14 +01:00
{% endcall %}
Add platform admin setting for letter branding Does two main things: - defines what ‘brands’ we support, in terms of the ID that DVLA use - adds a form to choose which branding a service uses (currently platform admin only, like email branding) By doing this we will be able to (with some more work) preview and send letters with a variety of different branding. Story: https://www.pivotaltracker.com/story/show/143506905
2017-04-19 16:11:28 +01:00
{% call row() %}
{{ text_field('Letter branding')}}
letter branding text fields should be optional
2019-02-05 17:21:09 +00:00
{{ optional_text_field(current_service.letter_branding.name) }}
use new letter branding instead of dvla organisation id new code is copied stylistically from the email branding patterns. Instead of `service.dvla_organisation`, there's now `service.letter_branding` and `service.letter_branding_id`. However, unlike email branding we're not currently showing a preview of the logo. That can come later when we work out how we want to do it.
2019-02-01 16:34:54 +00:00
{{ edit_field('Change', url_for('.service_set_letter_branding', service_id=current_service.id)) }}
Add platform admin setting for letter branding Does two main things: - defines what ‘brands’ we support, in terms of the ID that DVLA use - adds a form to choose which branding a service uses (currently platform admin only, like email branding) By doing this we will be able to (with some more work) preview and send letters with a variety of different branding. Story: https://www.pivotaltracker.com/story/show/143506905
2017-04-19 16:11:28 +01:00
{% endcall %}
Allow a platform admin user to set flexible data retention for a service for a specified notification type. Still a work in progress
2018-07-13 16:47:26 +01:00
{% call row() %}
Fix capitalisation on Data Retention
2018-07-17 15:56:28 +01:00
{{ text_field('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
{% call field() %}
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
{{ current_service.data_retention | join(', ', attribute='notification_type') }}
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
{% endcall %}
{{ edit_field('Change', url_for('.data_retention', service_id=current_service.id)) }}
Allow a platform admin user to set flexible data retention for a service for a specified notification type. Still a work in progress
2018-07-13 16:47:26 +01:00
{% endcall %}
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
{% for permission in service_permissions %}
{% if not service_permissions[permission].requires or current_service.has_permission(service_permissions[permission].requires) %}
{% call row() %}
{{ text_field(service_permissions[permission].title)}}
{{ boolean_field(current_service.has_permission(permission)) }}
{{ edit_field('Change', url_for(service_permissions[permission].endpoint or '.service_set_permission', service_id=current_service.id, permission=permission if not service_permissions[permission].endpoint else None)) }}
{% endcall %}
{% endif %}
{% endfor %}
Make email branding settings a table So that it matches the other settings on this page
2016-08-24 09:34:14 +01:00
{% endcall %}
Split platform admin settings into new section Makes it clearer what a normal user can change and what a platform admin can change.
2016-08-22 10:44:45 +01:00
Make live and research mode switches into buttons They change state, so they should be buttons (even if they’re still links).
2016-08-23 15:47:43 +01:00
<ul>
add deactivate service button on the service settings page only visible for platform admins looking at active services. no way to undo. no confirm button.
2016-11-02 16:53:40 +00:00
{% if current_service.active %}
<li class="bottom-gutter">
Changed deactivate service to archive service. need to deploy https://github.com/alphagov/notifications-api/pull/808 first
2017-01-31 09:54:51 +00:00
<a href="{{ url_for('.archive_service', service_id=current_service.id) }}" class="button">
flash up prompt when archiving a service same way as we do when deleting templates (also rename button from deactivate -> archive)
2016-11-08 14:33:53 +00:00
Archive service
add deactivate service button on the service settings page only visible for platform admins looking at active services. no way to undo. no confirm button.
2016-11-02 16:53:40 +00:00
</a>
</li>
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
<li class="bottom-gutter">
<a href="{{ url_for('.suspend_service', service_id=current_service.id) }}" class="button">
Suspend service
</a>
</li>
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
{% else %}
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
<li class="bottom-gutter">
<a href="{{ url_for('.resume_service', service_id=current_service.id) }}" class="button">
Resume service
</a>
</li>
add deactivate service button on the service settings page only visible for platform admins looking at active services. no way to undo. no confirm button.
2016-11-02 16:53:40 +00:00
{% endif %}
Make live and research mode switches into buttons They change state, so they should be buttons (even if they’re still links).
2016-08-23 15:47:43 +01:00
</ul>
Split platform admin settings into new section Makes it clearer what a normal user can change and what a platform admin can change.
2016-08-22 10:44:45 +01:00
{% endif %}
Added the shell service settings page [ci skip]
2015-11-30 16:16:58 +00:00
{% endblock %}
Remove platform admin toggle for basic view Since platform admins can use the new settings page, this commit: - links to that page - removes the platform-admin-only endpoint that switches basic view on and off
2018-07-10 10:09:17 +01:00
}
Reference in New Issue Copy Permalink