darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-02-26 21:31:11 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
203393de235631db0ce3c38dec85da170a634fba
notifications-admin/app/main/views/service_settings.py

1003 lines
36 KiB
Python
Raw Normal View History

Add data to copy into beta partners spreadsheet Currently we keep track of live services in the ‘beta partners’ spreadsheet: https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061 Every time a service goes live we need to enter some data into the spreadsheet about that service. Most of that data is copied from the request to go live ticket. This commit adds a line to the ticket with all the data needed by the spreadsheet. It’s in the same order as in the spreadsheet, and it’s tab-delimted so it should paste right on in there.
2018-08-30 10:46:13 +01:00
from datetime import datetime
import pytz
Working service integration.
2016-01-18 17:35:28 +00:00
from flask import (
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
abort,
Update the free allowance when the organisation type is changed. The free allowance affect the number of free text messages a services get per yer. This allowance is being set properly when an organisation is created by not updated. This PR updates the free allowance when the organisation type is updated. The free allowance can also be changed if service has an exceptional free allowance.
2018-03-02 10:48:59 +00:00
current_app,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
flash,
View function for request go live was always calling update service. Actually this should be no op until whatever workflow will take place in the real world is implemented. For the moment just display flash message to say request being processed and do nothing.
2016-03-09 14:30:50 +00:00
redirect,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
render_template,
View function for request go live was always calling update service. Actually this should be no op until whatever workflow will take place in the real world is implemented. For the moment just display flash message to say request being processed and do nothing.
2016-03-09 14:30:50 +00:00
request,
session,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
url_for,
View function for request go live was always calling update service. Actually this should be no op until whatever workflow will take place in the real world is implemented. For the moment just display flash message to say request being processed and do nothing.
2016-03-09 14:30:50 +00:00
)
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from flask_login import current_user, login_required
This pull request removes the need for the req and pay in the claims JWT. Use the new version of the notifications-python-client. This version no longer adds the req and pay to the claims of the jwt. The change is backward compatible so an older client that sends a JWT with the extra claims will pass authentication. Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well. The documentation has been updated to reflect this change. https://www.pivotaltracker.com/story/show/116971293
2016-04-15 11:04:35 +01:00
from notifications_python_client.errors import HTTPError
View function for request go live was always calling update service. Actually this should be no op until whatever workflow will take place in the real world is implemented. For the moment just display flash message to say request being processed and do nothing.
2016-03-09 14:30:50 +00:00
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from app import (
billing_api_client,
current_service,
email_branding_client,
inbound_number_client,
Refactor to add separate letter branding client We were getting all letter logos from a method in the email branding client. Since we will be adding more client methods to deal with letters, it makes things clearer to separate the email and letter branding clients.
2019-01-23 12:27:14 +00:00
letter_branding_client,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
organisations_client,
service_api_client,
user_api_client,
send zendesk rather than deskpro tickets
2018-04-24 17:37:15 +01:00
zendesk_client,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
)
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
from app.main import main
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
from app.main.forms import (
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
BrandingOptionsEmail,
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
ConfirmPasswordForm,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
FreeSMSAllowance,
InternationalSMSForm,
LinkOrganisationsForm,
OrganisationTypeForm,
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
RenameServiceForm,
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
RequestToGoLiveForm,
remove option for branding to sometimes not show search it wouldn't show search if there were under a certain amount of letter or email branding options - however we know there will always be more than that amount so lets remove some complexity. Also, rename the SearchTemplatesForm because it can search anything - it just prompts you to search by name is all.
2019-02-06 17:32:13 +00:00
SearchByNameForm,
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
ServiceContactDetailsForm,
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
ServiceDataRetentionEditForm,
ServiceDataRetentionForm,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
ServiceEditInboundNumberForm,
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
ServiceInboundNumberForm,
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
ServiceLetterContactBlockForm,
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
ServicePreviewBranding,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
ServiceReplyToEmailForm,
rename branding to email_branding to help transition to having letter branding as well
2019-02-01 16:31:34 +00:00
ServiceSetEmailBranding,
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
ServiceSetLetterBranding,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
ServiceSmsSenderForm,
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
ServiceSwitchChannelForm,
Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
SMSPrefixForm,
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
branding_options_dict,
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
)
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
from app.utils import (
Rename GovernmentDomain to AgreementInfo This better describes the data encapsulated by this class, and how we are now using it.
2018-03-09 14:53:04 +00:00
AgreementInfo,
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
email_safe,
user_has_permissions,
Refactor gov user check into a decorator We quite often use it in the same way as `@user_has_permissions`.
2018-12-12 13:10:46 +00:00
user_is_gov_user,
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
user_is_platform_admin,
)
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
Update service_id to a UUID from an integer. This commit must go along side a commit on the notifications-api app. There will be a breif outage until both app are deployed.
2016-02-02 14:24:08 +00:00
@main.route("/services/<service_id>/service-settings")
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
@login_required
remove any_ from has_permissions we branch on any_ to either say "require ALL these permissions" or "require ANY of these permissions". But we only ever call the decorator with one permission, or with any_=True, so it's unnecessary
2018-03-01 10:37:55 +00:00
@user_has_permissions('manage_service', 'manage_api_keys')
Add mocked service ID to all service-specific pages
2016-01-13 12:10:29 +00:00
def service_settings(service_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
return render_template('views/service-settings.html')
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
Update service_id to a UUID from an integer. This commit must go along side a commit on the notifications-api app. There will be a breif outage until both app are deployed.
2016-02-02 14:24:08 +00:00
@main.route("/services/<service_id>/service-settings/name", methods=['GET', 'POST'])
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
@login_required
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
@user_has_permissions('manage_service')
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
def service_name_change(service_id):
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not.
2017-10-04 11:49:32 +01:00
form = RenameServiceForm()
Add a WTForms-compatible textbox macro This macro: - accepts a WTForm form field as a parameter - renders a form field which follows the GOV.UK Elements patterns, both visually and in markup terms It then changes any page which uses either: - the old, non-WTForms macro or - the old, WTFforms `render_field` macro …to use this new macro and removes both of the old ones. It also adds the option to display hint text above the textbox.
2016-01-11 13:15:10 +00:00
Tidy up ‘change service name’ page - Make service name repopulate in textbox - More spacing between sections of the page
2016-06-20 13:33:29 +01:00
if request.method == 'GET':
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
form.name.data = current_service.name
Tidy up ‘change service name’ page - Make service name repopulate in textbox - More spacing between sections of the page
2016-06-20 13:33:29 +01:00
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
if form.validate_on_submit():
Don’t error if a user keeps same service name Sometimes a user will hit the green button without actually changing the service name (we saw this in a usability testing session). Currently this gives an error saying ‘service name already in use’, which is technically true (it’s in use by the current service) but practically just annoying. This commit adds some logic to silently ignore such requests.
2018-07-02 11:00:02 +01:00
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if form.name.data == current_service.name:
Don’t error if a user keeps same service name Sometimes a user will hit the green button without actually changing the service name (we saw this in a usability testing session). Currently this gives an error saying ‘service name already in use’, which is technically true (it’s in use by the current service) but practically just annoying. This commit adds some logic to silently ignore such requests.
2018-07-02 11:00:02 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
Pass service_id through to API '/service/unique' endpoint Notifications-api now needs the service_id to check the uniqueness of the service name when trying to change it. This is to allow a user to successfully change the pluralization or the case of their service name.
2018-02-13 11:27:57 +00:00
unique_name = service_api_client.is_service_name_unique(service_id, form.name.data, email_safe(form.name.data))
Don’t error if a user keeps same service name Sometimes a user will hit the green button without actually changing the service name (we saw this in a usability testing session). Currently this gives an error saying ‘service name already in use’, which is technically true (it’s in use by the current service) but practically just annoying. This commit adds some logic to silently ignore such requests.
2018-07-02 11:00:02 +01:00
- Change update service name to check that the name/email_from is unique across all services. - This is done using a new endpoint in the api. - Removed the AddServiceForm in favor or using the ServiceNameForm - Removed ServiceApiClient.find_all_service_email_from
2017-08-09 16:52:10 +01:00
if not unique_name:
form.name.errors.append("This service name is already in use")
return render_template('views/service-settings/name.html', form=form)
Don’t error if a user keeps same service name Sometimes a user will hit the green button without actually changing the service name (we saw this in a usability testing session). Currently this gives an error saying ‘service name already in use’, which is technically true (it’s in use by the current service) but practically just annoying. This commit adds some logic to silently ignore such requests.
2018-07-02 11:00:02 +01:00
Working service integration.
2016-01-18 17:35:28 +00:00
session['service_name_change'] = form.name.data
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
return redirect(url_for('.service_name_change_confirm', service_id=service_id))
return render_template(
Working service integration.
2016-01-18 17:35:28 +00:00
'views/service-settings/name.html',
Don’t error if a user keeps same service name Sometimes a user will hit the green button without actually changing the service name (we saw this in a usability testing session). Currently this gives an error saying ‘service name already in use’, which is technically true (it’s in use by the current service) but practically just annoying. This commit adds some logic to silently ignore such requests.
2018-07-02 11:00:02 +01:00
form=form,
)
Add confirm loop For pages where - we want you to be sure that you want to do what you’re about to do - we want to be sure it’s you trying to do the thing This adds a page that asks the user to confirm their password.
2016-01-07 16:24:43 +00:00
Update service_id to a UUID from an integer. This commit must go along side a commit on the notifications-api app. There will be a breif outage until both app are deployed.
2016-02-02 14:24:08 +00:00
@main.route("/services/<service_id>/service-settings/name/confirm", methods=['GET', 'POST'])
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
@login_required
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
@user_has_permissions('manage_service')
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
def service_name_change_confirm(service_id):
Added check for password on service change page, work in progress.
2016-01-22 16:34:36 +00:00
# Validate password for form
def _check_password(pwd):
Merging conflict with two_factor.py Fixed merge mistake with two_factor.py.
2016-03-30 09:58:10 +01:00
return user_api_client.verify_password(current_user.id, pwd)
Research mode - adds a new link on service settings page to switch service into/out of research mode - platform admin only - shows an indicator in the footer
2016-06-01 16:07:43 +01:00
Added check for password on service change page, work in progress.
2016-01-22 16:34:36 +00:00
form = ConfirmPasswordForm(_check_password)
Add a WTForms-compatible textbox macro This macro: - accepts a WTForm form field as a parameter - renders a form field which follows the GOV.UK Elements patterns, both visually and in markup terms It then changes any page which uses either: - the old, non-WTForms macro or - the old, WTFforms `render_field` macro …to use this new macro and removes both of the old ones. It also adds the option to display hint text above the textbox.
2016-01-11 13:15:10 +00:00
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
if form.validate_on_submit():
Service name uniqueness handled in all cases and tests passing.
2016-03-10 14:29:31 +00:00
try:
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
Make service API client do partial updates The service API client was updating every attribute of a service. Which, while kinda clunky, is fine… …until something calling it doesn’t pass in every attribute of the current service. It was then defaulting optional parameters to `None`. Which resulted in a bug whereby every time a service was set to live, its `reply_to_address` and `sms_sender_name` got overwritten to be empty. This commit changes the `update` method to only require the service ID, and pass whatever other named arguments it received straight through to the API. The API handles partial updates just fine (I think).
2016-08-11 12:32:38 +01:00
name=session['service_name_change'],
email_from=email_safe(session['service_name_change'])
)
Service name uniqueness handled in all cases and tests passing.
2016-03-10 14:29:31 +00:00
except HTTPError as e:
error_msg = "Duplicate service name '{}'".format(session['service_name_change'])
if e.status_code == 400 and error_msg in e.message['name']:
# Redirect the user back to the change service name screen
flash('This service name is already in use', 'error')
return redirect(url_for('main.service_name_change', service_id=service_id))
else:
raise e
else:
session.pop('service_name_change')
return redirect(url_for('.service_settings', service_id=service_id))
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
return render_template(
Working service integration.
2016-01-18 17:35:28 +00:00
'views/service-settings/confirm.html',
heading='Change your service name',
Added current_service to flask context and template context. Fix all tests and conflicts. Removed comment line.
2016-04-04 16:53:52 +01:00
form=form)
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 into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
@main.route("/services/<service_id>/service-settings/request-to-go-live")
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
@login_required
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
@user_has_permissions('manage_service')
Rename endpoint Every endpoint in this file is to do with a service. Putting service in the name is redundant.
2018-02-20 11:06:08 +00:00
def request_to_go_live(service_id):
Add line about MOU to checklist 2/3 of our incomplete requests to go live are incomplete because the Data Sharing and Financial Agreement isn’t signed. We reckon we can be pushier about this by saying it’s ‘incomplete’ where we know the agreement is signed. Where the agreement is signed we should confirm this, rather than make the line disappear. This is so it makes more sense to someone who sees it as ‘incomplete’, signs it, then comes back to the page. If we don’t know whether or not the agreement is signed we should wait until someone has got in touch with us by requesting to go live to figure it out. So that’s why we’re not showing that line at all.
2018-09-21 14:43:54 +01:00
agreement_signed = AgreementInfo.from_current_user().agreement_signed
Check for team members on request to go live page One of the things that we want to check before a service goes live is that they have at least two team members with the manage service permission. Anyone who can make a request to go live has this permission, so that means one additional user is needed. This is what we can automatically communicate to the user. Under the hood this makes use of the logic added in https://github.com/alphagov/notifications-admin/pull/1891
2018-02-27 11:33:26 +00:00
return render_template(
Add line about MOU to checklist 2/3 of our incomplete requests to go live are incomplete because the Data Sharing and Financial Agreement isn’t signed. We reckon we can be pushier about this by saying it’s ‘incomplete’ where we know the agreement is signed. Where the agreement is signed we should confirm this, rather than make the line disappear. This is so it makes more sense to someone who sees it as ‘incomplete’, signs it, then comes back to the page. If we don’t know whether or not the agreement is signed we should wait until someone has got in touch with us by requesting to go live to figure it out. So that’s why we’re not showing that line at all.
2018-09-21 14:43:54 +01:00
'views/service-settings/request-to-go-live.html',
show_agreement=agreement_signed is not None,
agreement_signed=agreement_signed,
Check for team members on request to go live page One of the things that we want to check before a service goes live is that they have at least two team members with the manage service permission. Anyone who can make a request to go live has this permission, so that means one additional user is needed. This is what we can automatically communicate to the user. Under the hood this makes use of the logic added in https://github.com/alphagov/notifications-admin/pull/1891
2018-02-27 11:33:26 +00:00
)
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
@main.route("/services/<service_id>/service-settings/submit-request-to-go-live", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
Refactor gov user check into a decorator We quite often use it in the same way as `@user_has_permissions`.
2018-12-12 13:10:46 +00:00
@user_is_gov_user
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
def submit_request_to_go_live(service_id):
Don’t let non-government users request to go live Only users who work for government can accept the terms of use. This will save us from having to email these requesters back telling them they need to find someone else to submit the request.
2018-12-12 12:54:22 +00:00
Put a form on the request to go live page This commit: - moves things around a bit on the request to go live page - sticks a textbox in there So when someone click the big green button, we will get a support ticket that looks something like: ``` From Test User <test@user.gov.uk> on behalf of Test Service (6ce466d0-fd6a-11e5-82f5-e0accb9d11a6) --- We’ll send about 1000 text messages in the first month, and then 10,000 text messages per month after that. Usage of our service is about 50% higher in March, at the end of the tax year. ```
2016-04-26 13:31:57 +01:00
form = RequestToGoLiveForm()
if form.validate_on_submit():
fix go live link
2018-04-27 15:47:47 +01:00
zendesk_client.create_ticket(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
subject='Request to go live - {}'.format(current_service.name),
fix go live link
2018-04-27 15:47:47 +01:00
message=(
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
'Service: {service_name}\n'
'{service_dashboard}\n'
fix go live link
2018-04-27 15:47:47 +01:00
'\n---'
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
'\nOrganisation type: {organisation_type}'
'\nAgreement signed: {agreement}'
Add info about checklist to ticket So that someone picking up a ticket can be warned that they should be checking these things.
2018-09-20 10:06:56 +01:00
'\nChecklist completed: {checklist}'
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
'\nEmails in next year: {volume_email}'
'\nText messages in next year: {volume_sms}'
'\nLetters in next year: {volume_letter}'
Add question about research consent Since GDPR came into effect it’s less clear about whether we can contact teams for user research purposes. If we make people opt-in (or not) we know we’re safe to contact them (or not). Since we mostly care about how services are using Notify for real (ie live services) or services that are considering adopting it (ie those who have contacted us with a question) it feels like the go-live process is the most appropriate place to collect this consent.
2018-08-30 11:51:34 +01:00
'\nConsent to research: {research_consent}'
Note existing live services in go live ticket It’s useful for analysing our growth to know if someone who’s requesting to go live is already a live user of Notify.
2018-12-12 12:22:38 +00:00
'\nOther live services: {existing_live}'
Add data to copy into beta partners spreadsheet Currently we keep track of live services in the ‘beta partners’ spreadsheet: https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061 Every time a service goes live we need to enter some data into the spreadsheet about that service. Most of that data is copied from the request to go live ticket. This commit adds a line to the ticket with all the data needed by the spreadsheet. It’s in the same order as in the spreadsheet, and it’s tab-delimted so it should paste right on in there.
2018-08-30 10:46:13 +01:00
'\n'
fix go live link
2018-04-27 15:47:47 +01:00
'\n---'
Add data to copy into beta partners spreadsheet Currently we keep track of live services in the ‘beta partners’ spreadsheet: https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061 Every time a service goes live we need to enter some data into the spreadsheet about that service. Most of that data is copied from the request to go live ticket. This commit adds a line to the ticket with all the data needed by the spreadsheet. It’s in the same order as in the spreadsheet, and it’s tab-delimted so it should paste right on in there.
2018-08-30 10:46:13 +01:00
'\n'
Use commas not tabs to delimit service info Zendesk strips out the tabs. Commas are the next best thing because Excel will automatically use them if you select ‘Split text into columns’.
2018-08-30 14:17:32 +01:00
'{service_id}, '
'{organisation}, '
'{service_name}, '
'{user_name}, '
'{user_email}, '
'-, '
'{date}, '
Strip commas from estimated volumes We suggest people format their numbers with commas when telling us how many things they’re going to send. This causes problems when we paste these values into a spreadsheet, because the commas get interpreted as column separators.
2018-12-11 10:47:28 +00:00
'{volume_sms_normalised}, '
'{volume_email_normalised}, '
'{volume_letter_normalised}'
fix go live link
2018-04-27 15:47:47 +01:00
).format(
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
service_name=current_service.name,
service_dashboard=url_for('main.service_dashboard', service_id=current_service.id, _external=True),
Add question about research consent Since GDPR came into effect it’s less clear about whether we can contact teams for user research purposes. If we make people opt-in (or not) we know we’re safe to contact them (or not). Since we mostly care about how services are using Notify for real (ie live services) or services that are considering adopting it (ie those who have contacted us with a question) it feels like the go-live process is the most appropriate place to collect this consent.
2018-08-30 11:51:34 +01:00
organisation_type=str(current_service.organisation_type).title(),
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
agreement=AgreementInfo.from_current_user().as_human_readable,
Tag request to go live tickets automatically At the moment we manually tag tickets as they come in so we can analyse how many of each type we’re getting. Further, we manually tag all the request to go live tickets once a month to analyse how many are complete/incomplete. All this tagging is useful, but quite time consuming. Notify already knows this information and – using the Zendesk API – we can tag them automatically. I’ve checked with Holly and this is the taxonomy we want to use.
2018-09-19 17:34:26 +01:00
checklist=current_service.go_live_checklist_completed_as_yes_no,
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
volume_email=form.volume_email.data,
Strip commas from estimated volumes We suggest people format their numbers with commas when telling us how many things they’re going to send. This causes problems when we paste these values into a spreadsheet, because the commas get interpreted as column separators.
2018-12-11 10:47:28 +00:00
volume_email_normalised=form.volume_email.data.replace(',', ''),
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
volume_sms=form.volume_sms.data,
Strip commas from estimated volumes We suggest people format their numbers with commas when telling us how many things they’re going to send. This causes problems when we paste these values into a spreadsheet, because the commas get interpreted as column separators.
2018-12-11 10:47:28 +00:00
volume_sms_normalised=form.volume_sms.data.replace(',', ''),
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
volume_letter=form.volume_letter.data,
Strip commas from estimated volumes We suggest people format their numbers with commas when telling us how many things they’re going to send. This causes problems when we paste these values into a spreadsheet, because the commas get interpreted as column separators.
2018-12-11 10:47:28 +00:00
volume_letter_normalised=form.volume_letter.data.replace(',', ''),
Add question about research consent Since GDPR came into effect it’s less clear about whether we can contact teams for user research purposes. If we make people opt-in (or not) we know we’re safe to contact them (or not). Since we mostly care about how services are using Notify for real (ie live services) or services that are considering adopting it (ie those who have contacted us with a question) it feels like the go-live process is the most appropriate place to collect this consent.
2018-08-30 11:51:34 +01:00
research_consent=form.research_consent.data.title(),
Note existing live services in go live ticket It’s useful for analysing our growth to know if someone who’s requesting to go live is already a live user of Notify.
2018-12-12 12:22:38 +00:00
existing_live='Yes' if user_api_client.user_has_live_services(current_user) else 'No',
Add data to copy into beta partners spreadsheet Currently we keep track of live services in the ‘beta partners’ spreadsheet: https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061 Every time a service goes live we need to enter some data into the spreadsheet about that service. Most of that data is copied from the request to go live ticket. This commit adds a line to the ticket with all the data needed by the spreadsheet. It’s in the same order as in the spreadsheet, and it’s tab-delimted so it should paste right on in there.
2018-08-30 10:46:13 +01:00
service_id=current_service.id,
organisation=AgreementInfo.from_current_user().owner,
user_name=current_user.name,
user_email=current_user.email_address,
date=datetime.now(tz=pytz.timezone('Europe/London')).strftime('%d/%m/%Y'),
fix go live link
2018-04-27 15:47:47 +01:00
),
ticket_type=zendesk_client.TYPE_QUESTION,
user_email=current_user.email_address,
Tag request to go live tickets automatically At the moment we manually tag tickets as they come in so we can analyse how many of each type we’re getting. Further, we manually tag all the request to go live tickets once a month to analyse how many are complete/incomplete. All this tagging is useful, but quite time consuming. Notify already knows this information and – using the Zendesk API – we can tag them automatically. I’ve checked with Holly and this is the taxonomy we want to use.
2018-09-19 17:34:26 +01:00
user_name=current_user.name,
tags=get_request_to_go_live_tags(current_service, current_user),
fix go live link
2018-04-27 15:47:47 +01:00
)
Put a form on the request to go live page This commit: - moves things around a bit on the request to go live page - sticks a textbox in there So when someone click the big green button, we will get a support ticket that looks something like: ``` From Test User <test@user.gov.uk> on behalf of Test Service (6ce466d0-fd6a-11e5-82f5-e0accb9d11a6) --- We’ll send about 1000 text messages in the first month, and then 10,000 text messages per month after that. Usage of our service is about 50% higher in March, at the end of the tax year. ```
2016-04-26 13:31:57 +01:00
Reword request to go live message We want to stop people writing support tickets that say something like “I’ve just submitted a request to go live, how long does the process take?”
2018-04-12 13:05:04 +01:00
flash('Thanks for your request to go live. We’ll get back to you within one working day.', 'default')
Add mocked service ID to all service-specific pages
2016-01-13 12:10:29 +00:00
return redirect(url_for('.service_settings', service_id=service_id))
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 into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
return render_template('views/service-settings/submit-request-to-go-live.html', form=form)
Put a form on the request to go live page This commit: - moves things around a bit on the request to go live page - sticks a textbox in there So when someone click the big green button, we will get a support ticket that looks something like: ``` From Test User <test@user.gov.uk> on behalf of Test Service (6ce466d0-fd6a-11e5-82f5-e0accb9d11a6) --- We’ll send about 1000 text messages in the first month, and then 10,000 text messages per month after that. Usage of our service is about 50% higher in March, at the end of the tax year. ```
2016-04-26 13:31:57 +01:00
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 service live and revert working, all tests passing.
2016-04-14 15:38:27 +01:00
@main.route("/services/<service_id>/service-settings/switch-live")
@login_required
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
@user_is_platform_admin
Make service live and revert working, all tests passing.
2016-04-14 15:38:27 +01:00
def service_switch_live(service_id):
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
Make service live and revert working, all tests passing.
2016-04-14 15:38:27 +01:00
# TODO This limit should be set depending on the agreement signed by
# with Notify.
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
message_limit=250000 if current_service.trial_mode else 50,
restricted=(not current_service.trial_mode)
Make service API client do partial updates The service API client was updating every attribute of a service. Which, while kinda clunky, is fine… …until something calling it doesn’t pass in every attribute of the current service. It was then defaulting optional parameters to `None`. Which resulted in a bug whereby every time a service was set to live, its `reply_to_address` and `sms_sender_name` got overwritten to be empty. This commit changes the `update` method to only require the service ID, and pass whatever other named arguments it received straight through to the API. The API handles partial updates just fine (I think).
2016-08-11 12:32:38 +01:00
)
Make service live and revert working, all tests passing.
2016-04-14 15:38:27 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
Research mode - adds a new link on service settings page to switch service into/out of research mode - platform admin only - shows an indicator in the footer
2016-06-01 16:07:43 +01:00
@main.route("/services/<service_id>/service-settings/research-mode")
@login_required
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
@user_is_platform_admin
Research mode - adds a new link on service settings page to switch service into/out of research mode - platform admin only - shows an indicator in the footer
2016-06-01 16:07:43 +01:00
def service_switch_research_mode(service_id):
Use model to toggle research mode Just a nice bit of encapsulation, rather than passing `current_service` through to a method on `current_service`.
2018-11-05 16:17:44 +00:00
current_service.toggle_research_mode()
platform admins can toggle services from seeing letters
2016-10-26 16:56:51 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
@main.route("/services/<service_id>/service-settings/email-auth")
@login_required
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
@user_is_platform_admin
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
def service_switch_email_auth(service_id):
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.switch_permission('email_auth')
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
Add button to toggle precompiled letters on/off
2018-02-21 17:41:19 +00:00
@main.route("/services/<service_id>/service-settings/can-send-precompiled-letter")
@login_required
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
@user_is_platform_admin
Add button to toggle precompiled letters on/off
2018-02-21 17:41:19 +00:00
def service_switch_can_send_precompiled_letter(service_id):
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.switch_permission('precompiled_letter')
Add button to toggle precompiled letters on/off
2018-02-21 17:41:19 +00:00
return redirect(url_for('.service_settings', service_id=service_id))
Make a contact_link required when turning upload_document permission on When a platform admin user clicks on the button to add the 'upload_document' permission to a service, they should be taken to the page to add a contact_link if the service does not already have one.
2018-06-05 17:23:47 +01:00
@main.route("/services/<service_id>/service-settings/can-upload-document", methods=['GET', 'POST'])
Add a button for switching 'upload_document' permission Adds a platform admin button to the service settings to turn on/off 'upload_document' service permission. The permission allows uploading documents to document-download-api through the post notification API endpoint.
2018-05-01 15:50:35 +01:00
@login_required
@user_is_platform_admin
def service_switch_can_upload_document(service_id):
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
form = ServiceContactDetailsForm()
Make a contact_link required when turning upload_document permission on When a platform admin user clicks on the button to add the 'upload_document' permission to a service, they should be taken to the page to add a contact_link if the service does not already have one.
2018-06-05 17:23:47 +01:00
# If turning the permission off, or turning it on and the service already has a contact_link,
# don't show the form to add the link
Don’t allow indexing on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods.
2018-10-26 12:13:04 +01:00
if current_service.has_permission('upload_document') or current_service.contact_link:
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.switch_permission('upload_document')
Make a contact_link required when turning upload_document permission on When a platform admin user clicks on the button to add the 'upload_document' permission to a service, they should be taken to the page to add a contact_link if the service does not already have one.
2018-06-05 17:23:47 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
if form.validate_on_submit():
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
contact_type = form.contact_details_type.data
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
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
contact_link=form.data[contact_type]
Make a contact_link required when turning upload_document permission on When a platform admin user clicks on the button to add the 'upload_document' permission to a service, they should be taken to the page to add a contact_link if the service does not already have one.
2018-06-05 17:23:47 +01:00
)
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.switch_permission('upload_document')
Make a contact_link required when turning upload_document permission on When a platform admin user clicks on the button to add the 'upload_document' permission to a service, they should be taken to the page to add a contact_link if the service does not already have one.
2018-06-05 17:23:47 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
return render_template('views/service-settings/contact_link.html', form=form)
Add a button for switching 'upload_document' permission Adds a platform admin button to the service settings to turn on/off 'upload_document' service permission. The permission allows uploading documents to document-download-api through the post notification API endpoint.
2018-05-01 15:50:35 +01:00
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
@main.route("/services/<service_id>/service-settings/archive", methods=['GET', 'POST'])
Add login_required for all endpoints where it makes sense. https://www.pivotaltracker.com/story/show/111240834
2016-01-11 16:03:41 +00:00
@login_required
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
@user_has_permissions('manage_service')
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
def archive_service(service_id):
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
if request.method == 'POST':
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
service_api_client.archive_service(service_id)
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
return redirect(url_for('.service_settings', service_id=service_id))
else:
flash('There\'s no way to reverse this! Are you sure you want to archive this service?', 'delete')
return service_settings(service_id)
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
@main.route("/services/<service_id>/service-settings/suspend", methods=["GET", "POST"])
@login_required
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
@user_has_permissions('manage_service')
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
def suspend_service(service_id):
if request.method == 'POST':
service_api_client.suspend_service(service_id)
return redirect(url_for('.service_settings', service_id=service_id))
else:
flash("This will suspend the service and revoke all api keys. Are you sure you want to suspend this service?",
'suspend')
return service_settings(service_id)
@main.route("/services/<service_id>/service-settings/resume", methods=["GET", "POST"])
@login_required
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
@user_has_permissions('manage_service')
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
def resume_service(service_id):
if request.method == 'POST':
service_api_client.resume_service(service_id)
return redirect(url_for('.service_settings', service_id=service_id))
else:
flash("This will resume the service. New api key are required for this service to use the API.", 'resume')
return service_settings(service_id)
Add page to change a service's contact link Added a page which lets users with the 'manage_service' permission change the contact link for their service. There are no links to this page yet since only services using document download will need to set a contact link.
2018-06-05 10:37:41 +01:00
@main.route("/services/<service_id>/service-settings/contact-link", methods=['GET', 'POST'])
@login_required
@user_has_permissions('manage_service')
def service_set_contact_link(service_id):
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
form = ServiceContactDetailsForm()
Add page to change a service's contact link Added a page which lets users with the 'manage_service' permission change the contact link for their service. There are no links to this page yet since only services using document download will need to set a contact link.
2018-06-05 10:37:41 +01:00
if request.method == 'GET':
Don’t allow indexing on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods.
2018-10-26 12:13:04 +01:00
contact_details = current_service.contact_link
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
contact_type = check_contact_details_type(contact_details)
field_to_update = getattr(form, contact_type)
form.contact_details_type.data = contact_type
field_to_update.data = contact_details
Add page to change a service's contact link Added a page which lets users with the 'manage_service' permission change the contact link for their service. There are no links to this page yet since only services using document download will need to set a contact link.
2018-06-05 10:37:41 +01:00
if form.validate_on_submit():
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
contact_type = form.contact_details_type.data
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
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
contact_link=form.data[contact_type]
Add page to change a service's contact link Added a page which lets users with the 'manage_service' permission change the contact link for their service. There are no links to this page yet since only services using document download will need to set a contact link.
2018-06-05 10:37:41 +01:00
)
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
return redirect(url_for('.service_settings', service_id=current_service.id))
Add page to change a service's contact link Added a page which lets users with the 'manage_service' permission change the contact link for their service. There are no links to this page yet since only services using document download will need to set a contact link.
2018-06-05 10:37:41 +01:00
return render_template('views/service-settings/contact_link.html', form=form)
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
@main.route("/services/<service_id>/service-settings/set-reply-to-email", methods=['GET'])
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
@login_required
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
@user_has_permissions('manage_service')
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
def service_set_reply_to_email(service_id):
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
return redirect(url_for('.service_email_reply_to', service_id=service_id))
@main.route("/services/<service_id>/service-settings/email-reply-to", methods=['GET'])
@login_required
remove any_ from has_permissions we branch on any_ to either say "require ALL these permissions" or "require ANY of these permissions". But we only ever call the decorator with one permission, or with any_=True, so it's unnecessary
2018-03-01 10:37:55 +00:00
@user_has_permissions('manage_service', 'manage_api_keys')
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
def service_email_reply_to(service_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
return render_template('views/service-settings/email_reply_to.html')
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
@main.route("/services/<service_id>/service-settings/email-reply-to/add", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
def service_add_email_reply_to(service_id):
form = ServiceReplyToEmailForm()
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
first_email_address = current_service.count_email_reply_to_addresses == 0
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
if form.validate_on_submit():
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
service_api_client.add_reply_to_email_address(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
email_address=form.email_address.data,
is_default=first_email_address if first_email_address else form.is_default.data
Make service API client do partial updates The service API client was updating every attribute of a service. Which, while kinda clunky, is fine… …until something calling it doesn’t pass in every attribute of the current service. It was then defaulting optional parameters to `None`. Which resulted in a bug whereby every time a service was set to live, its `reply_to_address` and `sms_sender_name` got overwritten to be empty. This commit changes the `update` method to only require the service ID, and pass whatever other named arguments it received straight through to the API. The API handles partial updates just fine (I think).
2016-08-11 12:32:38 +01:00
)
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
return redirect(url_for('.service_email_reply_to', service_id=service_id))
return render_template(
'views/service-settings/email-reply-to/add.html',
form=form,
first_email_address=first_email_address)
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
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
@main.route(
"/services/<service_id>/service-settings/email-reply-to/<reply_to_email_id>/edit",
methods=['GET', 'POST'],
endpoint="service_edit_email_reply_to"
)
@main.route(
"/services/<service_id>/service-settings/email-reply-to/<reply_to_email_id>/delete",
methods=['GET'],
endpoint="service_confirm_delete_email_reply_to"
)
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
@login_required
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
@user_has_permissions('manage_service')
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
def service_edit_email_reply_to(service_id, reply_to_email_id):
form = ServiceReplyToEmailForm()
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
reply_to_email_address = current_service.get_email_reply_to_address(reply_to_email_id)
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
if request.method == 'GET':
form.email_address.data = reply_to_email_address['email_address']
form.is_default.data = reply_to_email_address['is_default']
if form.validate_on_submit():
service_api_client.update_reply_to_email_address(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
reply_to_email_id=reply_to_email_id,
email_address=form.email_address.data,
is_default=True if reply_to_email_address['is_default'] else form.is_default.data
)
return redirect(url_for('.service_email_reply_to', service_id=service_id))
Update confirmation messages for delete sms-sender and delete reply-to-email
2018-11-16 17:05:59 +00:00
if (request.endpoint == "main.service_confirm_delete_email_reply_to"):
flash("Are you sure you want to delete this email reply-to address?", 'delete')
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
return render_template(
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
'views/service-settings/email-reply-to/edit.html',
form=form,
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
reply_to_email_address_id=reply_to_email_id,
)
@main.route("/services/<service_id>/service-settings/email-reply-to/<reply_to_email_id>/delete", methods=['POST'])
@login_required
@user_has_permissions('manage_service')
def service_delete_email_reply_to(service_id, reply_to_email_id):
Update service_api_client to use new endpoints API now has separate endpoints to archive email reply-to addresses and SMS senders, so we no longer need to use the endpoints for updating.
2018-04-26 15:09:37 +01:00
service_api_client.delete_reply_to_email_address(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
service_id=current_service.id,
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
reply_to_email_id=reply_to_email_id,
)
return redirect(url_for('.service_email_reply_to', service_id=service_id))
Users can set a value that appears as the sender of a text message. It can be up to eleven characters alpha numeric, no special characters allowed.
2016-07-01 13:47:22 +01:00
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
@main.route("/services/<service_id>/service-settings/set-inbound-number", methods=['GET', 'POST'])
merged codes
2017-08-10 10:29:31 +01:00
@login_required
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
@user_has_permissions('manage_service')
merged codes
2017-08-10 10:29:31 +01:00
def service_set_inbound_number(service_id):
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
available_inbound_numbers = inbound_number_client.get_available_inbound_sms_numbers()
inbound_numbers_value_and_label = [
(number['id'], number['number']) for number in available_inbound_numbers['data']
]
no_available_numbers = available_inbound_numbers['data'] == []
form = ServiceInboundNumberForm(
inbound_number_choices=inbound_numbers_value_and_label
)
if form.validate_on_submit():
service_api_client.add_sms_sender(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
sms_sender=form.inbound_number.data,
is_default=True,
inbound_number_id=form.inbound_number.data
)
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.force_permission('inbound_sms', on=True)
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-inbound-number.html',
form=form,
no_available_numbers=no_available_numbers,
)
merged codes
2017-08-10 10:29:31 +01:00
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
@main.route("/services/<service_id>/service-settings/sms-prefix", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
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
def service_set_sms_prefix(service_id):
form = SMSPrefixForm(enabled=(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
'on' if current_service.prefix_sms else 'off'
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
))
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
form.enabled.label.text = 'Start all text messages with ‘{}:’'.format(current_service.name)
Change wording based on Thom’s feedback
2017-11-06 14:12:25 +00:00
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
if form.validate_on_submit():
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
POST to the correct endpoint when updating `prefix_sms_with_service_name` is a computed attribute on the service model. It’s where we get the value from, and the API does some work to get it from the database, or derive it from the default SMS sender. It can’t be updated, because it’s not itself a database column. `prefix_sms` is the name of the actual database column. This is the thing that we need to update. This will go away eventually.
2017-11-06 15:08:34 +00:00
prefix_sms=(form.enabled.data == 'on')
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
)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/sms-prefix.html',
form=form
)
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
@main.route("/services/<service_id>/service-settings/set-international-sms", methods=['GET', 'POST'])
Tell users international text messaging is coming Users might be interested in international SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-04-27 14:26:25 +01:00
@login_required
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
@user_has_permissions('manage_service')
Tell users international text messaging is coming Users might be interested in international SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-04-27 14:26:25 +01:00
def service_set_international_sms(service_id):
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
form = InternationalSMSForm(
Make a service model and use for permissions Having the service floating about as JSON is a bit flakey. Could easily introduce a mistake where you mistype the name of a key and silently get `None`. Also means doing awkward things like `if 'permission' in current_service['permissions']`, whereas for users we can do the much cleaner `user.has_permission()`. So this commit: - introduces a model - adds a `.has_permission` method similar to the one we have for users
2018-07-20 08:43:02 +01:00
enabled='on' if current_service.has_permission('international_sms') else 'off'
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
)
if form.validate_on_submit():
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.force_permission(
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
'international_sms',
Refactor permissions handling to use sets We didn’t like the nested conditional way of doing this. So this commit refactors the way that permissions are set by: - splitting it up into multiple, clearly named methods - treating the list of permissions as `set`s, which they naturally are, because you can’t have duplicate permissions (this removes a lot of the complexity around having to test for membership before removing a permission, for example)
2017-09-27 11:58:37 +01:00
on=(form.enabled.data == 'on'),
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
)
return redirect(
url_for(".service_settings", service_id=service_id)
)
Tell users international text messaging is coming Users might be interested in international SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-04-27 14:26:25 +01:00
return render_template(
'views/service-settings/set-international-sms.html',
Allow services to turn international SMS on/off We didn’t make this self-service before because the pricing information wasn’t published (ie we had to send it to services that asked for it). Now that we publish pricing information in the app, there’s no reason why services can’t make an informed decision about whether they want international SMS or not. So this commit: - removes the platform admin button - adds some radio buttons that our users can click with their mice
2017-09-26 14:05:02 +01:00
form=form,
Tell users international text messaging is coming Users might be interested in international SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-04-27 14:26:25 +01:00
)
Add settings page for inbound SMS Users might be interested in inbound SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-06-07 14:14:53 +01:00
@main.route("/services/<service_id>/service-settings/set-inbound-sms", methods=['GET'])
@login_required
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
@user_has_permissions('manage_service')
Add settings page for inbound SMS Users might be interested in inbound SMS. And when it’s fully available, they’ll probably be able to control whether it’s on/off for their service. Until they point, the only way of getting it 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.
2017-06-07 14:14:53 +01:00
def service_set_inbound_sms(service_id):
return render_template(
'views/service-settings/set-inbound-sms.html',
)
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
@main.route("/services/<service_id>/service-settings/set-letters", methods=['GET'])
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
@login_required
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
@user_has_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
def service_set_letters(service_id):
Use 301 to redirect old URL 301 is a `permanent redirect`, which is semantically more accurate.
2019-01-30 13:36:01 +00:00
return redirect(
url_for(
'.service_set_channel',
service_id=current_service.id,
channel='letter',
),
code=301,
)
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
@main.route("/services/<service_id>/service-settings/set-<channel>", methods=['GET', 'POST'])
@login_required
@user_has_permissions('manage_service')
def service_set_channel(service_id, channel):
if channel not in {'email', 'sms', 'letter'}:
abort(404)
form = ServiceSwitchChannelForm(
channel=channel,
enabled='on' if current_service.has_permission(channel) else 'off'
Allows services to choose if they can send letters Our support ticket analysis shows that the most common action request after going live is turning on letters. We just do this for any team that requests it – there’s no gatekeeping. So we should just allow people to make the change themselves. This will be a better experience for our users, and less work for us. The design of the page replicates roughly what we have for international text messaging.
2018-01-19 13:45:54 +00:00
)
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
Allows services to choose if they can send letters Our support ticket analysis shows that the most common action request after going live is turning on letters. We just do this for any team that requests it – there’s no gatekeeping. So we should just allow people to make the change themselves. This will be a better experience for our users, and less work for us. The design of the page replicates roughly what we have for international text messaging.
2018-01-19 13:45:54 +00:00
if form.validate_on_submit():
Move service permission handle inside the model These helper functions for modifying a service permission were just floating around loose in the view code. A much better home for them is on the model. This will also make it easy to reuse them in other views if we ever need to.
2018-11-05 16:53:03 +00:00
current_service.force_permission(
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
channel,
Allows services to choose if they can send letters Our support ticket analysis shows that the most common action request after going live is turning on letters. We just do this for any team that requests it – there’s no gatekeeping. So we should just allow people to make the change themselves. This will be a better experience for our users, and less work for us. The design of the page replicates roughly what we have for international text messaging.
2018-01-19 13:45:54 +00:00
on=(form.enabled.data == 'on'),
)
return redirect(
url_for(".service_settings", service_id=service_id)
)
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
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
return render_template(
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
'views/service-settings/set-{}.html'.format(channel),
Allows services to choose if they can send letters Our support ticket analysis shows that the most common action request after going live is turning on letters. We just do this for any team that requests it – there’s no gatekeeping. So we should just allow people to make the change themselves. This will be a better experience for our users, and less work for us. The design of the page replicates roughly what we have for international text messaging.
2018-01-19 13:45:54 +00:00
form=form,
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
)
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
@main.route("/services/<service_id>/service-settings/set-auth-type", methods=['GET'])
@login_required
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
@user_has_permissions('manage_service')
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
def service_set_auth_type(service_id):
return render_template(
'views/service-settings/set-auth-type.html',
)
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
@main.route("/services/<service_id>/service-settings/letter-contacts", methods=['GET'])
@login_required
remove any_ from has_permissions we branch on any_ to either say "require ALL these permissions" or "require ANY of these permissions". But we only ever call the decorator with one permission, or with any_=True, so it's unnecessary
2018-03-01 10:37:55 +00:00
@user_has_permissions('manage_service', 'manage_api_keys')
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
def service_letter_contact_details(service_id):
letter_contact_details = service_api_client.get_letter_contacts(service_id)
return render_template(
'views/service-settings/letter-contact-details.html',
letter_contact_details=letter_contact_details)
@main.route("/services/<service_id>/service-settings/letter-contact/add", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
def service_add_letter_contact(service_id):
form = ServiceLetterContactBlockForm()
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
first_contact_block = current_service.count_letter_contact_details == 0
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
if form.validate_on_submit():
service_api_client.add_letter_contact(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
contact_block=form.letter_contact_block.data.replace('\r', '') or None,
is_default=first_contact_block if first_contact_block else form.is_default.data
)
Allow letter templates to select the default contact block from the list
2018-01-03 10:44:36 +00:00
if request.args.get('from_template'):
return redirect(
url_for('.set_template_sender', service_id=service_id, template_id=request.args.get('from_template'))
)
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
return redirect(url_for('.service_letter_contact_details', service_id=service_id))
return render_template(
'views/service-settings/letter-contact/add.html',
form=form,
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
first_contact_block=first_contact_block,
)
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
@main.route("/services/<service_id>/service-settings/letter-contact/<letter_contact_id>/edit", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
def service_edit_letter_contact(service_id, letter_contact_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
letter_contact_block = current_service.get_letter_contact_block(letter_contact_id)
form = ServiceLetterContactBlockForm(
letter_contact_block=letter_contact_block['contact_block']
)
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
if request.method == 'GET':
form.is_default.data = letter_contact_block['is_default']
if form.validate_on_submit():
service_api_client.update_letter_contact(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
letter_contact_id=letter_contact_id,
contact_block=form.letter_contact_block.data.replace('\r', '') or None,
is_default=True if letter_contact_block['is_default'] else form.is_default.data
)
return redirect(url_for('.service_letter_contact_details', service_id=service_id))
return render_template(
'views/service-settings/letter-contact/edit.html',
form=form,
letter_contact_id=letter_contact_block['id'])
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
@main.route("/services/<service_id>/service-settings/sms-sender", methods=['GET'])
@login_required
remove any_ from has_permissions we branch on any_ to either say "require ALL these permissions" or "require ANY of these permissions". But we only ever call the decorator with one permission, or with any_=True, so it's unnecessary
2018-03-01 10:37:55 +00:00
@user_has_permissions('manage_service', 'manage_api_keys')
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
def service_sms_senders(service_id):
return render_template(
'views/service-settings/sms-senders.html',
)
@main.route("/services/<service_id>/service-settings/sms-sender/add", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
def service_add_sms_sender(service_id):
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
form = ServiceSmsSenderForm()
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
first_sms_sender = current_service.count_sms_senders == 0
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
if form.validate_on_submit():
service_api_client.add_sms_sender(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
sms_sender=form.sms_sender.data.replace('\r', '') or None,
is_default=first_sms_sender if first_sms_sender else form.is_default.data
)
return redirect(url_for('.service_sms_senders', service_id=service_id))
return render_template(
'views/service-settings/sms-sender/add.html',
form=form,
first_sms_sender=first_sms_sender)
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
@main.route(
"/services/<service_id>/service-settings/sms-sender/<sms_sender_id>/edit",
methods=['GET', 'POST'],
endpoint="service_edit_sms_sender"
)
@main.route(
"/services/<service_id>/service-settings/sms-sender/<sms_sender_id>/delete",
methods=['GET'],
endpoint="service_confirm_delete_sms_sender"
)
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
@login_required
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
@user_has_permissions('manage_service')
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
def service_edit_sms_sender(service_id, sms_sender_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
sms_sender = current_service.get_sms_sender(sms_sender_id)
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
is_inbound_number = sms_sender['inbound_number_id']
if is_inbound_number:
form = ServiceEditInboundNumberForm(is_default=sms_sender['is_default'])
else:
form = ServiceSmsSenderForm(**sms_sender)
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
if form.validate_on_submit():
service_api_client.update_sms_sender(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.id,
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
sms_sender_id=sms_sender_id,
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
sms_sender=sms_sender['sms_sender'] if is_inbound_number else form.sms_sender.data.replace('\r', ''),
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
is_default=True if sms_sender['is_default'] else form.is_default.data
)
return redirect(url_for('.service_sms_senders', service_id=service_id))
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
form.is_default.data = sms_sender['is_default']
Update confirmation messages for delete sms-sender and delete reply-to-email
2018-11-16 17:05:59 +00:00
if (request.endpoint == "main.service_confirm_delete_sms_sender"):
flash("Are you sure you want to delete this text message sender?", 'delete')
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
return render_template(
'views/service-settings/sms-sender/edit.html',
form=form,
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
sms_sender=sms_sender,
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
inbound_number=is_inbound_number,
Update confirmation messages for delete sms-sender and delete reply-to-email
2018-11-16 17:05:59 +00:00
sms_sender_id=sms_sender_id
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
)
@main.route(
"/services/<service_id>/service-settings/sms-sender/<sms_sender_id>/delete",
methods=['POST'],
)
@login_required
@user_has_permissions('manage_service')
def service_delete_sms_sender(service_id, sms_sender_id):
Update service_api_client to use new endpoints API now has separate endpoints to archive email reply-to addresses and SMS senders, so we no longer need to use the endpoints for updating.
2018-04-26 15:09:37 +01:00
service_api_client.delete_sms_sender(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
service_id=current_service.id,
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
sms_sender_id=sms_sender_id,
Fixed broken edit functionality
2017-10-30 14:30:43 +00:00
)
Allow delete email reply to address, SMS senders For both SMS senders and email reply to addresses this commit adds: - a delete link - a confirmation loop It doesn’t let users delete: - default SMS senders or reply to addresses (they always have to have one) - inbound numbers It assumes that the API will allow updating of an attribute named `active` on the respective database rows. It could work in a different way. We can’t do complete deletion though because these will still be keyed to notifications.
2017-11-14 11:31:20 +00:00
return redirect(url_for('.service_sms_senders', service_id=service_id))
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
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
@main.route("/services/<service_id>/service-settings/set-letter-contact-block", methods=['GET', 'POST'])
@login_required
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
@user_has_permissions('manage_service')
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
def service_set_letter_contact_block(service_id):
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
if not current_service.has_permission('letter'):
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
abort(403)
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
form = ServiceLetterContactBlockForm(letter_contact_block=current_service.letter_contact_block)
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
if form.validate_on_submit():
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
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
letter_contact_block=form.letter_contact_block.data.replace('\r', '') or None
)
Go back to template after editing contact details Users who go to edit the contact details for a letter from the template page get very confused when they click save and are dumped on the settings page. It doesn’t match the way editing other parts of letter works, and you can’t see an accurate preview of the changes from the settings page. So this commit changes the flow to go from the _edit contact details_ page back to the _view template_ page when the user has got there by clicking the blue _Edit_ button on the _view template_ page.
2017-04-03 09:54:03 +01:00
if request.args.get('from_template'):
return redirect(
url_for('.view_template', service_id=service_id, template_id=request.args.get('from_template'))
)
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
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-letter-contact-block.html',
form=form
)
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
@main.route("/services/<service_id>/service-settings/set-organisation-type", methods=['GET', 'POST'])
@login_required
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
@user_is_platform_admin
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
def set_organisation_type(service_id):
Don’t allow use of `.get()` on service model Making people use a property is a sure way to make sure they’re spelling the name of the property correctly, and allows us to easily swap out properties that call through to the underlying JSON, and properties which are implemented as methods. The API should always return something in the JSON for a property, even if it’s just `None`.
2018-10-27 13:09:03 +01:00
form = OrganisationTypeForm(organisation_type=current_service.organisation_type)
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
if form.validate_on_submit():
Update the free allowance when the organisation type is changed. The free allowance affect the number of free text messages a services get per yer. This allowance is being set properly when an organisation is created by not updated. This PR updates the free allowance when the organisation type is updated. The free allowance can also be changed if service has an exceptional free allowance.
2018-03-02 10:48:59 +00:00
free_sms_fragment_limit = current_app.config['DEFAULT_FREE_SMS_FRAGMENT_LIMITS'].get(
form.organisation_type.data)
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
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
organisation_type=form.organisation_type.data,
)
Update the free allowance when the organisation type is changed. The free allowance affect the number of free text messages a services get per yer. This allowance is being set properly when an organisation is created by not updated. This PR updates the free allowance when the organisation type is updated. The free allowance can also be changed if service has an exceptional free allowance.
2018-03-02 10:48:59 +00:00
billing_api_client.create_or_update_free_sms_fragment_limit(service_id, free_sms_fragment_limit)
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
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-organisation-type.html',
form=form,
)
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
@main.route("/services/<service_id>/service-settings/set-free-sms-allowance", methods=['GET', 'POST'])
@login_required
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
@user_is_platform_admin
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
def set_free_sms_allowance(service_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
form = FreeSMSAllowance(free_sms_allowance=current_service.free_sms_fragment_limit)
Use the revise api endpoints without current-year parameter
2017-11-09 13:18:09 +00:00
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
if form.validate_on_submit():
update free sms fragment limit to go via billing client instead of service
2017-12-04 16:03:11 +00:00
billing_api_client.create_or_update_free_sms_fragment_limit(service_id, form.free_sms_allowance.data)
Use the revise api endpoints without current-year parameter
2017-11-09 13:18:09 +00:00
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
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-free-sms-allowance.html',
form=form,
)
Change organisations to email branding
2018-02-07 10:30:49 +00:00
@main.route("/services/<service_id>/service-settings/set-email-branding", methods=['GET', 'POST'])
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
@login_required
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
@user_is_platform_admin
Change organisations to email branding
2018-02-07 10:30:49 +00:00
def service_set_email_branding(service_id):
email_branding = email_branding_client.get_all_email_branding()
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
rename branding to email_branding to help transition to having letter branding as well
2019-02-01 16:31:34 +00:00
form = ServiceSetEmailBranding(
all_branding_options=get_branding_as_value_and_label(email_branding),
current_branding=current_service.email_branding_id,
Put the currently selected branding top of list There’s something that feels a bit off about not being able to see the name of the currently-selected branding when you land on the page. Putting it at the top also means that you can easily switch back to it if you change your mind.
2018-08-31 17:21:12 +01:00
)
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
if form.validate_on_submit():
Refactor some of the logic into form It’s messy having a lot of logic in the view methods. Handling the form stuff can be better encapsulated inside the `Form` subclass itself.
2018-08-31 17:31:26 +01:00
return redirect(url_for(
'.service_preview_email_branding',
service_id=service_id,
branding_style=form.branding_style.data,
))
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
return render_template(
'views/service-settings/set-email-branding.html',
form=form,
remove option for branding to sometimes not show search it wouldn't show search if there were under a certain amount of letter or email branding options - however we know there will always be more than that amount so lets remove some complexity. Also, rename the SearchTemplatesForm because it can search anything - it just prompts you to search by name is all.
2019-02-06 17:32:13 +00:00
search_form=SearchByNameForm()
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
)
@main.route("/services/<service_id>/service-settings/preview-email-branding", methods=['GET', 'POST'])
@login_required
@user_is_platform_admin
def service_preview_email_branding(service_id):
branding_style = request.args.get('branding_style', None)
Remove branding_type from set_email_branding page Includes updates to the controller so branding_type is got from the email_branding model instead of from user input. Follows on from: https://github.com/alphagov/notifications-admin/pull/2249
2018-08-29 11:36:50 +01:00
form = ServicePreviewBranding(branding_style=branding_style)
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
if form.validate_on_submit():
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
Make handling of `None` values in forms clearer If the browser posts the value of `<input value='None'>` to the server it does so as a string. We want to post a value of `None` (actually JSON `null`) to the API. To do this we: - set the value in the form class to `'None'` (ie a string) - convert to `None` (as a type) afterwards However seeing `x = 'None'` in code looks a bit like a mistake. So to make sure it looks deliberate and clear what is happening this commit: - makes a reusable constant for `'None'` - adds a comment explaining why it’s a string
2018-11-12 09:04:39 +00:00
email_branding=form.branding_style.data
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
)
return redirect(url_for('.service_settings', service_id=service_id))
only set organisation on GET and add allowed fields to service client we were overwriting it before validating the form for POST, so lost info
2016-08-12 12:37:18 +01:00
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
return render_template(
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
'views/service-settings/preview-email-branding.html',
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
form=form,
Add preview step to branding selection flow Gives platform admins a chance to preview the combination of brand type and custom brand (coloured banner and logo) set for service before saving.
2018-08-02 14:46:01 +01:00
service_id=service_id,
action=url_for('main.service_preview_email_branding', service_id=service_id),
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
)
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
@main.route("/services/<service_id>/service-settings/set-letter-branding", methods=['GET', 'POST'])
@login_required
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
@user_is_platform_admin
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
def service_set_letter_branding(service_id):
letter_branding = letter_branding_client.get_all_letter_branding()
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
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
form = ServiceSetLetterBranding(
all_branding_options=get_branding_as_value_and_label(letter_branding),
current_branding=current_service.letter_branding_id,
Refactor setting value on letter branding form WTForms lets you pre-populate a form’s value by passing it in as an argument to the constructor. This will be good for us because it will let us access that value in the constructor later on.
2018-11-05 12:16:38 +00:00
)
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
if form.validate_on_submit():
Use model to update service properties We have a lot of places in settings where we update something by passing in the `service_id`. `current_service` already knows about `service_id`, so it’s cleaner to encapsulate these updates inside the model.
2018-11-05 16:03:11 +00:00
current_service.update(
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
letter_branding=form.branding_style.data
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
)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-letter-branding.html',
form=form,
remove option for branding to sometimes not show search it wouldn't show search if there were under a certain amount of letter or email branding options - however we know there will always be more than that amount so lets remove some complexity. Also, rename the SearchTemplatesForm because it can search anything - it just prompts you to search by name is all.
2019-02-06 17:32:13 +00:00
search_form=SearchByNameForm()
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
)
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
@main.route("/services/<service_id>/service-settings/request-letter-branding", methods=['GET', 'POST'])
@login_required
@user_has_permissions('manage_service')
def request_letter_branding(service_id):
return render_template(
'views/service-settings/request-letter-branding.html',
Add an ‘add logo’ button Because some people don’t know they can put their own logo on letters: > The HM Government Logo is at the top of the letter and we can't see > a way of putting the [organisation] logo on > We are intending to use the letter template feature for the first time > and wondered whether the branding is configurable or whether the HM > Government header is the standard default. > Can we replace HM Government logo with our own in the letter? IF yes, > then how? > I don't seem to be able to set the branding on the letters to be > [organisation]. it's always HM government. Is there something that > needs enabling for this account? No-one actually wants the HM Government logo (no-one is sending real letters using it). So we should leave the space blank and put a button there prompting people to add their own logo.
2019-01-23 10:16:43 +00:00
from_template=request.args.get('from_template'),
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
)
link-services-to-organisations
2018-02-12 09:26:13 +00:00
@main.route("/services/<service_id>/service-settings/link-service-to-organisation", methods=['GET', 'POST'])
@login_required
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
@user_is_platform_admin
link-services-to-organisations
2018-02-12 09:26:13 +00:00
def link_service_to_organisation(service_id):
organisations = organisations_client.get_organisations()
current_organisation = organisations_client.get_service_organisation(service_id).get('id', None)
form = LinkOrganisationsForm(
choices=convert_dictionary_to_wtforms_choices_format(organisations, 'id', 'name'),
organisations=current_organisation
)
if form.validate_on_submit():
if form.organisations.data != current_organisation:
organisations_client.update_service_organisation(
service_id,
form.organisations.data
)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/link-service-to-organisation.html',
link-service-to-organisations-tweaks
2018-02-14 16:13:11 +00:00
has_organisations=organisations,
link-services-to-organisations
2018-02-12 09:26:13 +00:00
form=form,
)
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
@main.route("/services/<service_id>/branding-request/email", methods=['GET', 'POST'])
@login_required
@user_has_permissions('manage_service')
def branding_request(service_id):
Fix issue that happens with branding_style of None Setting the branding_style to 'None' causes the API to remove the email_branding field from a service model. The branding request page controller was depending on that value being to present get the brand type. The email preview page (used in an iframe on various pages) wasn't able to recognise a branding_style of 'None', causing a blank page to render.
2018-08-30 11:38:47 +01:00
branding_type = 'govuk'
if current_service.email_branding:
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
branding_type = current_service.email_branding['brand_type']
Update branding request page It was getting the brand_type from the service model. This changes the controller to get it from the new email_branding model instead.
2018-08-29 15:20:46 +01:00
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
form = BrandingOptionsEmail(
Fix issue that happens with branding_style of None Setting the branding_style to 'None' causes the API to remove the email_branding field from a service model. The branding request page controller was depending on that value being to present get the brand type. The email preview page (used in an iframe on various pages) wasn't able to recognise a branding_style of 'None', causing a blank page to render.
2018-08-30 11:38:47 +01:00
options=branding_type
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
)
if form.validate_on_submit():
zendesk_client.create_ticket(
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
subject='Email branding request - {}'.format(current_service.name),
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
message=(
Add organisation info to branding requests This will let us know which organisation the person asking for the branding is from. This should reduce how often we have to go back to them and ask.
2018-07-10 16:08:32 +01:00
'Organisation: {}\n'
Tweaked the formatting of the Zendesk messages
2018-06-15 15:11:13 +01:00
'Service: {}\n'
'{}\n'
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
'\n---'
'\nBranding requested: {}'
).format(
Fix org info in branding requests with known orgs This wasn’t looking quite right in the case where an organisation is in our list of domains.
2018-07-10 17:18:50 +01:00
AgreementInfo.from_current_user().as_info_for_branding_request,
Use service model to look up service attributes This is better than just keying into the JSON because it means you get an exception straight away when looking up a key that doesn’t exist (which via mocking you could ordinarily miss).
2018-07-20 08:42:01 +01:00
current_service.name,
url_for('main.service_dashboard', service_id=current_service.id, _external=True),
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
branding_options_dict[form.options.data],
),
ticket_type=zendesk_client.TYPE_QUESTION,
user_email=current_user.email_address,
user_name=current_user.name,
Auto-tag email branding requests
2018-09-21 09:01:58 +01:00
tags=['notify_action_add_branding'],
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
)
flash((
'Thanks for your branding request. We’ll get back to you '
'within one working day.'
), 'default')
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/branding/email-options.html',
form=form,
)
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
@main.route("/services/<service_id>/data-retention", methods=['GET'])
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
@login_required
@user_is_platform_admin
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
def data_retention(service_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
return render_template(
'views/service-settings/data-retention.html',
)
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
@main.route("/services/<service_id>/data-retention/add", methods=['GET', 'POST'])
@login_required
@user_is_platform_admin
def add_data_retention(service_id):
form = ServiceDataRetentionForm()
if form.validate_on_submit():
service_api_client.create_service_data_retention(service_id,
form.notification_type.data,
form.days_of_retention.data)
return redirect(url_for('.data_retention', service_id=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
return render_template(
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
'views/service-settings/data-retention/add.html',
form=form
)
@main.route("/services/<service_id>/data-retention/<data_retention_id>/edit", methods=['GET', 'POST'])
@login_required
@user_is_platform_admin
def edit_data_retention(service_id, data_retention_id):
Refactor settings page to use service model There’s a lot of code in service settings which: - talks to the API directly through the clients - passes that information through to the Jinja template By encapsulating this logic in the service model: - the Jinja template can access the data directly - the logic can be reused across multiple methods
2018-10-26 17:31:49 +01:00
data_retention_item = current_service.get_data_retention_item(data_retention_id)
Addressing comments from PR review. Update tests Use a table to display the data retention data.
2018-07-18 15:31:34 +01:00
form = ServiceDataRetentionEditForm(days_of_retention=data_retention_item['days_of_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
if form.validate_on_submit():
service_api_client.update_service_data_retention(service_id, data_retention_id, form.days_of_retention.data)
return redirect(url_for('.data_retention', service_id=service_id))
return render_template(
'views/service-settings/data-retention/edit.html',
form=form,
data_retention_id=data_retention_id,
Addressing comments from PR review. Update tests Use a table to display the data retention data.
2018-07-18 15:31:34 +01:00
notification_type=data_retention_item['notification_type']
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
)
Change organisations to email branding
2018-02-07 10:30:49 +00:00
def get_branding_as_value_and_label(email_branding):
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
return [
Change organisations to email branding
2018-02-07 10:30:49 +00:00
(branding['id'], branding['name'])
for branding in email_branding
Add a page to set organisation and branding option Platform admin only. Adds radio buttons to choose one of: - three hard-coded branding options - organisations from a list provided by the API
2016-08-08 10:28:40 +01:00
]
link-services-to-organisations
2018-02-12 09:26:13 +00:00
def convert_dictionary_to_wtforms_choices_format(dictionary, value, label):
return [
(item[value], item[label]) for item in dictionary
]
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
def check_contact_details_type(contact_details):
if contact_details.startswith('http'):
return 'url'
elif '@' in contact_details:
return 'email_address'
else:
return 'phone_number'
Tag request to go live tickets automatically At the moment we manually tag tickets as they come in so we can analyse how many of each type we’re getting. Further, we manually tag all the request to go live tickets once a month to analyse how many are complete/incomplete. All this tagging is useful, but quite time consuming. Notify already knows this information and – using the Zendesk API – we can tag them automatically. I’ve checked with Holly and this is the taxonomy we want to use.
2018-09-19 17:34:26 +01:00
def get_request_to_go_live_tags(service, user):
return list(_get_request_to_go_live_tags(
service,
AgreementInfo.from_user(user).agreement_signed,
))
def _get_request_to_go_live_tags(service, agreement_signed):
BASE = 'notify_request_to_go_live'
yield BASE
if service.go_live_checklist_completed and agreement_signed:
Fix missing ‘complete’ tag in go live request This tag was not showing up in the call to the Zendesk API because the return value of a generator is not included as a member of that generator (on things `yield`ed from it are).
2018-09-24 17:47:56 +01:00
yield BASE + '_complete'
return
Tag request to go live tickets automatically At the moment we manually tag tickets as they come in so we can analyse how many of each type we’re getting. Further, we manually tag all the request to go live tickets once a month to analyse how many are complete/incomplete. All this tagging is useful, but quite time consuming. Notify already knows this information and – using the Zendesk API – we can tag them automatically. I’ve checked with Holly and this is the taxonomy we want to use.
2018-09-19 17:34:26 +01:00
Refactor to reduce nesting and repetition
2018-09-21 09:13:12 +01:00
for test, tag in (
(True, ''),
(not service.go_live_checklist_completed, '_checklist'),
(not agreement_signed, '_mou'),
(service.needs_to_add_email_reply_to_address, '_email_reply_to'),
(not service.has_team_members, '_team_member'),
(not service.has_templates, '_template_content'),
(service.needs_to_change_sms_sender, '_sms_sender'),
Tag request to go live tickets automatically At the moment we manually tag tickets as they come in so we can analyse how many of each type we’re getting. Further, we manually tag all the request to go live tickets once a month to analyse how many are complete/incomplete. All this tagging is useful, but quite time consuming. Notify already knows this information and – using the Zendesk API – we can tag them automatically. I’ve checked with Holly and this is the taxonomy we want to use.
2018-09-19 17:34:26 +01:00
):
Refactor to reduce nesting and repetition
2018-09-21 09:13:12 +01:00
if test:
Fix missing ‘complete’ tag in go live request This tag was not showing up in the call to the Zendesk API because the return value of a generator is not included as a member of that generator (on things `yield`ed from it are).
2018-09-24 17:47:56 +01:00
yield BASE + '_incomplete' + tag
Reference in New Issue Copy Permalink