darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-05-30 02:50:03 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
4d0da6594de60fcf37dc7796279462e32072d7a1
notifications-admin/app/templates/views/service-settings.html

404 lines
15 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
Normalise heading sizes Since we added template folders the templates page has had a ‘medium’ sized heading, where other pages have stuck with a ‘large’ size. This commit rationalises the decision around which pages have which heading size: - ‘navigation’ pages (eg templates, team members, email reply to addresses) have medium sized headings - transactional pages (ie ones which have a green button) keep the larger heading size
2019-04-23 10:03:28 +01:00
<h1 class="heading-medium">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
Make center column of table wider Most of the content of our ‘settings’ tables is in the value, not the key. The value is in the middle column. So we should allocate the most space to the value. The previous layout was based on the premise that most pages divided the grid like this: ``` _______ _______ _______ _______ _______ _______ _______ _______ | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | | | | | | | 2/8 | 2/8 | 2/8 | 2/8 | | | | | | |–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––| | | | | | | 3/8 | 3/8 | | | | | | |–Label–––––––––––––––––|–Value––––––––––––Link–| | | | | |_______________|_______________________|_______________________| ``` This was because a lot of pages had a left column for emails, and a right column for text messages, so it felt consistent for tables to always default to 50% of the width of the main column. This consistency has faded with time, especially as we added letters. So this commit changes these tables to allocate more space to the central column, but still sticking to the grid like this: ``` _______ _______ _______ _______ _______ _______ _______ _______ | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | | | | | | | | | | | 2/8 | 2/8 | 4/8 | | | | | |–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––| | | | | | | | 2/8 | 3/8 | 1/8 | | | | | | | |–Label–––––––––|–Value–––––––––––––––––|–––Link| |_______________|_______________|_______________________|_______| ``` Since there’s more space to display the value of a setting this commit also truncates settings that are too long to fit in the width of the column (for example a long email address) rather than the previous behaviour of truncating them. This all just makes things look a bit cleaner.
2019-04-23 10:21:19 +01:00
<div class="bottom-gutter-3-2 settings-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 %}
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(
Normalise heading sizes Since we added template folders the templates page has had a ‘medium’ sized heading, where other pages have stuck with a ‘large’ size. This commit rationalises the decision around which pages have which heading size: - ‘navigation’ pages (eg templates, team members, email reply to addresses) have medium sized headings - transactional pages (ie ones which have a green button) keep the larger heading size
2019-04-23 10:03:28 +01:00
caption='Email settings',
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
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') %}
Update 'reply-to email address'
2019-07-09 16:43:54 +01:00
{{ text_field('Reply-to email 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(
Update `change` links and headings (#3064) * Update Settings titles * Update Change links on settings * Update Team members Change link * Update Settings pages headings
2019-07-25 11:52:13 +01:00
'Manage',
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') }}
Only show relevant choices of email branding Users who work in local government can’t have GOV.UK branding on their emails. And only those working for Companies House (for example) can request the Companies House branding. This commit adds: - new choices of email branding, which offer the name of the branding, rather than the style - logic to filter this list to only the applicable options, based on what we know about the user, service and organisation This is a change from the previous approach which put the onus on users to figure out the style of branding they wanted, when we might already know that a lot of the options weren’t available to them, or would be inconsistent with the branding of other services in their organisation.
2019-09-12 13:45:35 +01:00
{{ text_field(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',
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
url_for('.branding_request', service_id=current_service.id, branding_type="email"),
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
Enable users to turn send file by email setting on and off
2020-02-17 15:32:19 +00:00
{% call settings_row(if_has_permission='email') %}
{{ text_field('Send files by email') }}
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
{{ text_field(current_service.contact_link if current_service.contact_link else "Not set up", truncate=true) }}
Enable users to turn send file by email setting on and off
2020-02-17 15:32:19 +00:00
{{ edit_field(
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
'Manage',
url_for('.send_files_by_email_contact_details', service_id=current_service.id),
Enable users to turn send file by email setting on and off
2020-02-17 15:32:19 +00:00
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(
Normalise heading sizes Since we added template folders the templates page has had a ‘medium’ sized heading, where other pages have stuck with a ‘large’ size. This commit rationalises the decision around which pages have which heading size: - ‘navigation’ pages (eg templates, team members, email reply to addresses) have medium sized headings - transactional pages (ie ones which have a green button) keep the larger heading size
2019-04-23 10:03:28 +01:00
caption='Text message settings',
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
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') %}
Update `change` links and headings (#3064) * Update Settings titles * Update Change links on settings * Update Team members Change link * Update Settings pages headings
2019-07-25 11:52:13 +01:00
{{ text_field('Text message senders') }}
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 '') %}
fix one more place where senders weren't sanitised make sure everything is using the `nl2br` formatter that properly wraps it in markdown to keep everything sanitised nicely. Also write a couple of tests
2020-01-22 16:13:25 +00:00
{{ current_service.default_sms_sender | nl2br if current_service.default_sms_sender else 'None'}}
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.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(
Update `change` links and headings (#3064) * Update Settings titles * Update Change links on settings * Update Team members Change link * Update Settings pages headings
2019-07-25 11:52:13 +01:00
'Manage',
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') %}
Update text message setting name Update text message setting name for `Start text messages with service name`
2019-07-22 10:13:33 +01:00
{{ text_field('Start text messages 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') %}
Update `change` links and headings (#3064) * Update Settings titles * Update Change links on settings * Update Team members Change link * Update Settings pages headings
2019-07-25 11:52:13 +01:00
{{ text_field('Send international text messages') }}
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
{{ 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(
Normalise heading sizes Since we added template folders the templates page has had a ‘medium’ sized heading, where other pages have stuck with a ‘large’ size. This commit rationalises the decision around which pages have which heading size: - ‘navigation’ pages (eg templates, team members, email reply to addresses) have medium sized headings - transactional pages (ie ones which have a green button) keep the larger heading size
2019-04-23 10:03:28 +01:00
caption='Letter settings',
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
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') }}
Allow deleting default letter contact blocks It’s possible to delete default letter contact blocks because there is a fallback – having a blank letter contact block. This is different to SMS senders and reply to addresses. For this to make sense it also means: - adding the ‘blank’ letter contact block to the list of letter contact blocks - having a way of setting the default back to being blank
2019-07-05 13:17:48 +01:00
{% call field(status='' if current_service.count_letter_contact_details else 'default') %}
{% if current_service.default_letter_contact_block %}
{{ current_service.default_letter_contact_block_html }}
{% elif current_service.count_letter_contact_details %}
Blank
{% else %}
Not set
{% 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
{% 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(
Update `change` links and headings (#3064) * Update Settings titles * Update Change links on settings * Update Team members Change link * Update Settings pages headings
2019-07-25 11:52:13 +01:00
'Manage',
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',
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
url_for('.branding_request', service_id=current_service.id, branding_type="letter"),
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
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 %}
Even out the spacing on the settings page This makes the spacing above and below each heading on the settings page consistent.
2019-07-22 11:36:40 +01:00
<h2 class="heading-medium top-gutter-0">Your service is in trial mode</h2>
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
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">You can only:</p>
Update trial mode content
2019-11-20 11:25:36 +00:00
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 class='list list-bullet'>
Update trial mode content
2019-11-20 11:25:36 +00:00
<li>send {{ current_service.message_limit }} text messages and emails per day</li>
Update lead in and second bullet
2019-11-20 11:32:42 +00:00
<li>send messages to yourself and other people in your team</li>
Update trial mode content
2019-11-20 11:25:36 +00:00
<li>create letter templates, but not send them</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>
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">
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') %}
Update link text
2019-11-22 14:17:15 +00:00
To remove these restrictions, you can send us a
Update all links to use GOVUK Frontend style Includes: - turning off :visited styles to match existing design - swapping heading classes used to make links bold for the GOVUK Frontend bold override class - adding visually hidden text to some links to make them work when isolated from their context We may need to revisit whether some links, such as those for documentation and features, may benefit from having some indication that their target has been visited.
2019-12-06 07:53:46 +00:00
<a class="govuk-link govuk-link--no-visited-state" href="{{ url_for('.request_to_go_live', service_id=current_service.id) }}">request to go live</a>.
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
{% else %}
Your service manager can ask to have these restrictions removed.
{% endif %}
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>
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
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 %}
Even out the spacing on the settings page This makes the spacing above and below each heading on the settings page consistent.
2019-07-22 11:36:40 +01:00
<h2 class="heading-medium top-gutter-0">Your service is live</h2>
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
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">
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
You can send up to
{{ "{:,}".format(current_service.message_limit) }} messages
per day.
</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">
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
Problems or comments?
Update all links to use GOVUK Frontend style Includes: - turning off :visited styles to match existing design - swapping heading classes used to make links bold for the GOVUK Frontend bold override class - adding visually hidden text to some links to make them work when isolated from their context We may need to revisit whether some links, such as those for documentation and features, may benefit from having some indication that their target has been visited.
2019-12-06 07:53:46 +00:00
<a class="govuk-link govuk-link--no-visited-state" 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
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
<div class="settings-table body-copy-table top-gutter-4-3">
<h2 class="heading-medium">Platform admin settings</h2>
{% call mapping_table(
caption='Settings',
field_headings=['Label', 'Value', 'Action'],
field_headings_visible=False,
caption_visible=False
) %}
{% call row() %}
{{ text_field('Live')}}
Fix unnecessary call to organisation API endpoint We’re caching the organisation name, but still talking to the API to see if the organisation exists. `Service().organisation_id` only goes to the JSON for the service. `Service().organisation` makes a separate API call. We only need the former to know if a service belongs to an organisation.
2020-04-02 15:06:03 +01:00
{% if current_service.trial_mode and not current_service.organisation_id %}
Make ‘you must set organisation’ text shorter So it fits in the column.
2019-05-20 16:14:41 +01:00
{{ text_field('No (organisation must be set first)') }}
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{{ text_field('') }}
{% else %}
{{ boolean_field(not current_service.trial_mode) }}
{{ edit_field('Change', url_for('.service_switch_live', service_id=current_service.id)) }}
{% endif %}
{% 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
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01: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)) }}
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 %}
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
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{% call row() %}
{{ text_field('Organisation')}}
Stop allowing the service org type to be changed The service organisation type will either be the same as the org type of the service's organisation or will be set by a user when creating a new service. This removes the ability to change it from the platform admin settings table.
2019-07-08 09:44:22 +01:00
{% call field() %}
{% if current_service.organisation_id %}
Update all links to use GOVUK Frontend style Includes: - turning off :visited styles to match existing design - swapping heading classes used to make links bold for the GOVUK Frontend bold override class - adding visually hidden text to some links to make them work when isolated from their context We may need to revisit whether some links, such as those for documentation and features, may benefit from having some indication that their target has been visited.
2019-12-06 07:53:46 +00:00
<a class="govuk-link govuk-link--no-visited-state" href="{{ url_for('main.organisation_dashboard', org_id=current_service.organisation_id) }}">
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
{{ current_service.organisation_name }}
Stop allowing the service org type to be changed The service organisation type will either be the same as the org type of the service's organisation or will be set by a user when creating a new service. This removes the ability to change it from the platform admin settings table.
2019-07-08 09:44:22 +01:00
</a>
{% else %}
<span class="table-field-status-default">Not set</span>
{% endif %}
{% if current_service.organisation_type %}
<div class="hint">
Remove duplication of org type lookup There’s a couple of places where we’re looking up the label for the type of organisation. Having this repeated in multiple places means it’s more likely we forget to update one of these places when making a change. This commit looks up from the tuple in the organisation model, which is where other code references this stuff from. This is only possible now that we don’t have duplicate keys (ie GP practice doesn’t share a key any more).
2019-08-27 16:32:30 +01:00
{{ current_service.organisation_type_label }}
Stop allowing the service org type to be changed The service organisation type will either be the same as the org type of the service's organisation or will be set by a user when creating a new service. This removes the ability to change it from the platform admin settings table.
2019-07-08 09:44:22 +01:00
</div>
{% endif %}
{% endcall %}
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{{ edit_field('Change', url_for('.link_service_to_organisation', service_id=current_service.id)) }}
{% endcall %}
Stop allowing the service org type to be changed The service organisation type will either be the same as the org type of the service's organisation or will be set by a user when creating a new service. This removes the ability to change it from the platform admin settings table.
2019-07-08 09:44:22 +01:00
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{% call row() %}
{{ text_field('Free text message allowance')}}
{{ text_field('{:,}'.format(current_service.free_sms_fragment_limit)) }}
{{ edit_field('Change', url_for('.set_free_sms_allowance', service_id=current_service.id)) }}
{% endcall %}
{% call row() %}
{{ text_field('Email branding' )}}
{{ text_field(current_service.email_branding_name) }}
{{ edit_field('Change', url_for('.service_set_email_branding', service_id=current_service.id)) }}
{% endcall %}
{% call row() %}
{{ text_field('Letter branding')}}
{{ optional_text_field(current_service.letter_branding.name) }}
{{ edit_field('Change', url_for('.service_set_letter_branding', service_id=current_service.id)) }}
{% endcall %}
{% call row() %}
{{ text_field('Data retention')}}
{% call field() %}
{{ current_service.data_retention | join(', ', attribute='notification_type') }}
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
{% endcall %}
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{{ edit_field('Change', url_for('.data_retention', service_id=current_service.id)) }}
{% 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
Make platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01: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 %}
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 platform admin settings table body copy size No reason why it should be smaller and harder to read than the user-facing settings table.
2019-04-23 10:31:32 +01:00
{% endcall %}
</div>
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
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 %}
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
{% if current_service.active and (current_service.trial_mode or current_user.platform_admin) %}
<p class="top-gutter-1-2">
<span class="page-footer-delete-link page-footer-delete-link-without-button">
Convert warning links to govuk-link--destructive Converts links in the following: - the page-footer component - the table component - the browse-list component - the notification status, when reporting failures - validation messaging in the whitelist page
2020-02-10 12:13:24 +00:00
<a class="govuk-link govuk-link--destructive" href="{{ url_for('.archive_service', service_id=current_service.id) }}">
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
Delete this service
</a>
</span>
{% if current_user.platform_admin %}
<span class="page-footer-delete-link">
Convert warning links to govuk-link--destructive Converts links in the following: - the page-footer component - the table component - the browse-list component - the notification status, when reporting failures - validation messaging in the whitelist page
2020-02-10 12:13:24 +00:00
<a href="{{ url_for('.suspend_service', service_id=current_service.id) }}" class="govuk-link govuk-link--destructive page-footer-delete-link">
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
Suspend service
</a>
</span>
{% endif %}
</p>
{% endif %}
{% if (not current_service.active) and current_user.platform_admin %}
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">
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
<div class="hint bottom-gutter-1-2">
Service suspended
</div>
<span class="page-footer-delete-link page-footer-delete-link-without-button">
Convert warning links to govuk-link--destructive Converts links in the following: - the page-footer component - the table component - the browse-list component - the notification status, when reporting failures - validation messaging in the whitelist page
2020-02-10 12:13:24 +00:00
<a class="govuk-link govuk-link--destructive" href="{{ url_for('.resume_service', service_id=current_service.id) }}">
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
Resume service
</a>
</span>
</p>
{% 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