darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-15 07:18:58 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
2c7e7fbc4b3a465e384bfc0d2b082902a9dcd8e2
notifications-admin/app/main/views/service_settings.py

1128 lines
42 KiB
Python
Raw Normal View History

Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
from collections import OrderedDict
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
from datetime import datetime
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
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,
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
jsonify,
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
)
Have permissions decorators check user signed in Rather than force us to write the decorators in a specific order let’s just have one decorator call the other. This should make fewer lines of code, and fewer annoying test failures. It also means that the same way of raising a `401` (through the `current_app` method) is used everywhere.
2019-07-01 15:22:08 +01:00
from flask_login import current_user
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
Use utils function to parse datetime strings Rather than hard-coding a format string in a bunch of different places we can use the function we already have in utils. This commit also refactors some logic around password resets to put the date-parsing changes in the most sensible bit of the codebase, so it’s clearer what the intention of the view-layer code is.
2020-01-21 12:23:30 +00:00
from notifications_utils.timezones import utc_string_to_aware_gmt_datetime
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,
Make one method for comma-formatting numbers We were doing this a few different ways in different places.
2019-07-08 14:09:29 +01:00
format_thousands,
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
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,
Send request to api to check if reply-to address is working
2019-05-09 17:55:10 +01:00
notification_api_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,
)
move (non-api) clients (inc redis) from app/__init__.py to extensions when clients are defined in app/__init__.py, it increases the chance of cyclical imports. By moving module level client singletons out to a separate extensions file, we stop cyclical imports, but keep the same code flow - the clients are still initialised in `create_app` in `__init__.py`. The redis client in particular is no longer separate - previously redis was set up on the `NotifyAdminAPIClient` base class, but now there's one singleton in `app.extensions`. This was done so that we can access redis from outside of the existing clients.
2019-02-14 14:25:31 +00:00
from app.extensions import zendesk_client
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 (
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
BrandingOptions,
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
ConfirmPasswordForm,
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
EstimateUsageForm,
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,
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
PreviewBranding,
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,
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,
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
ServiceOnOffSettingForm,
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,
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,
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
SetEmailBranding,
SetLetterBranding,
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,
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 (
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
DELIVERED_STATUSES,
FAILURE_STATUSES,
SENDING_STATUSES,
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
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
PLATFORM_ADMIN_SERVICE_PERMISSIONS = OrderedDict([
('inbound_sms', {'title': 'Receive inbound SMS', 'requires': 'sms', 'endpoint': '.service_set_inbound_number'}),
Changing the labels on the sevice setting page. We added `Upload letters` to the platform admin service settings, which makes is confusing when next to `Upload documents`. Also `User auth type editting` is a confusing label `User auth type editting` --> `Email authentication` `Uploading documents` --> `Send file by email`
2019-08-06 16:57:40 +01:00
('email_auth', {'title': 'Email authentication'}),
Add upload letters permission to service settings page The upload_letters permission can only be changed by Platform Admin users. It works in a similar way to the inbound_sms nested permission - you only see the row in the table if you have the 'letter' permission, but the 'letter' and 'upload_letters' are still separate permissions and changing one does not affect the other.
2019-08-05 13:51:31 +01:00
('upload_letters', {'title': 'Uploading letters', 'requires': 'letter'}),
Add international_letters permission to settings page This is a permission that can only be toggled by Platform Admin and which requires the `letter` permission in order to be turned on.
2020-03-09 14:17:20 +00:00
('international_letters', {'title': 'Send international letters', 'requires': 'letter'}),
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
])
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings")
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):
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
return render_template(
'views/service-settings.html',
service_permissions=PLATFORM_ADMIN_SERVICE_PERMISSIONS
)
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/name", methods=['GET', 'POST'])
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/name/confirm", methods=['GET', 'POST'])
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/request-to-go-live/estimate-usage", methods=['GET', 'POST'])
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
@user_has_permissions('manage_service')
def estimate_usage(service_id):
form = EstimateUsageForm(
volume_email=current_service.volume_email,
volume_sms=current_service.volume_sms,
volume_letter=current_service.volume_letter,
Don’t prefil answer to research consent question We were treating `None` (not answered) the same as `False` (previously answered no).
2019-03-01 12:22:57 +00:00
consent_to_research={
True: 'yes',
False: 'no',
}.get(current_service.consent_to_research),
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
)
if form.validate_on_submit():
current_service.update(
volume_email=form.volume_email.data,
volume_sms=form.volume_sms.data,
volume_letter=form.volume_letter.data,
consent_to_research=(form.consent_to_research.data == 'yes'),
)
return redirect(url_for(
'main.request_to_go_live',
service_id=service_id,
))
return render_template(
'views/service-settings/estimate-usage.html',
form=form,
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/request-to-go-live", methods=['GET'])
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):
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(
Allow GPs to click through to the agreement We want GPs to be able to accept the agreement online. But at the moment they don’t get automatically assigned to organisations. So we need to let them enter the agreement accepting journey even if they don’t have an organisation set up.
2019-09-04 15:55:09 +01:00
'views/service-settings/request-to-go-live.html'
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/request-to-go-live", methods=['POST'])
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
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
zendesk_client.create_ticket(
subject='Request to go live - {}'.format(current_service.name),
message=(
'Service: {service_name}\n'
'{service_dashboard}\n'
'\n---'
'\nOrganisation type: {organisation_type}'
'\nAgreement signed: {agreement}'
Let people go live without filling the volumes At the moment it 500s because it can’t format the `None` values as numbers. In the future we will stop people requesting to go live until they’ve provided this info. For now it has to be optional.
2019-02-27 17:05:02 +00:00
'\nEmails in next year: {volume_email_formatted}'
'\nText messages in next year: {volume_sms_formatted}'
'\nLetters in next year: {volume_letter_formatted}'
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
'\nConsent to research: {research_consent}'
'\nOther live services: {existing_live}'
'\n'
'\n---'
Keep email address in go live ticket It’s useful because it’s not easy to see in the Zendesk UI.
2019-05-14 11:17:47 +01:00
'\nRequest sent by {email_address}'
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
'\n'
).format(
service_name=current_service.name,
service_dashboard=url_for('main.service_dashboard', service_id=current_service.id, _external=True),
organisation_type=str(current_service.organisation_type).title(),
Remove the user-specific agreement pages We used to give users the right version of the agreement by guessing their organisation from their email address. Now we do it by looking at the organisation of the service they’re looking at. In other words, users should only be downloading the agreement as part of the go live journey, not outside it. This is because we think that users will get confused if they download the agreement and: - find there’s nowhere to physically sign it - think that accepting the agreement is all they need to do to go live Maintaining two paths to download the agreement also makes the code more complicated, and makes it harder to update the content on these pages.
2019-07-12 09:03:35 +01:00
agreement=current_service.organisation.as_agreement_statement_for_go_live_request(
current_user.email_domain
),
Make one method for comma-formatting numbers We were doing this a few different ways in different places.
2019-07-08 14:09:29 +01:00
volume_email_formatted=format_thousands(current_service.volume_email),
volume_sms_formatted=format_thousands(current_service.volume_sms),
volume_letter_formatted=format_thousands(current_service.volume_letter),
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
research_consent='Yes' if current_service.consent_to_research else 'No',
Move some methods from the API client to the model They make more sense being on the model, and it doesn’t make any sense to duplicate them.
2019-06-07 09:14:14 +01:00
existing_live='Yes' if current_user.live_services else 'No',
Keep email address in go live ticket It’s useful because it’s not easy to see in the Zendesk UI.
2019-05-14 11:17:47 +01:00
email_address=current_user.email_address,
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
),
ticket_type=zendesk_client.TYPE_QUESTION,
user_email=current_user.email_address,
user_name=current_user.name,
Refactor go live tags into service model Since this function only takes one argument, a service, it might as well be a method of the service.
2019-04-04 11:27:05 +01:00
tags=current_service.request_to_go_live_tags,
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +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
Update service with the user that requested to go live. When a service is marked as live update the service with the go live datetime.
2019-04-16 15:01:54 +01:00
current_service.update(go_live_user=current_user.id)
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
flash('Thanks for your request to go live. We’ll get back to you within one working day.', 'default')
return redirect(url_for('.service_settings', service_id=service_id))
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/switch-live", methods=["GET", "POST"])
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):
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
form = ServiceOnOffSettingForm(
name="Make service live",
enabled=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
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
if form.validate_on_submit():
Automate counting of live services and orgs Returns the data calculated by the API. Stored in Redis against a hardcoded key so that no-one hammering the home page is directly hitting the database.
2019-04-10 17:20:51 +01:00
current_service.update_status(live=form.enabled.data)
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
return redirect(url_for('.service_settings', service_id=service_id))
Make service live and revert working, all tests passing.
2016-04-14 15:38:27 +01:00
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
return render_template(
'views/service-settings/set-service-setting.html',
title="Make service live",
form=form,
)
platform admins can toggle services from seeing letters
2016-10-26 16:56:51 +01:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/switch-count-as-live", methods=["GET", "POST"])
Allow excluding services from live services count Adds a front end for: https://github.com/alphagov/notifications-api/pull/2417 > Sometimes we have to make a few services for what really is one > service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also > have our own test services which aren’t included in the count of live > services. We currently count these as one service by not including > them in the beta partners spreadsheet.
2019-03-25 14:46:42 +00:00
@user_is_platform_admin
def service_switch_count_as_live(service_id):
form = ServiceOnOffSettingForm(
name="Count in list of live services",
enabled=current_service.count_as_live,
truthy='Yes',
falsey='No',
)
if form.validate_on_submit():
Update live services count when service is counted If we change our mind and decide whether a service should/should not be counted in the list of live services then we should also drop the cache which stores the count of how many live services there are.
2019-07-08 14:32:18 +01:00
current_service.update_count_as_live(form.enabled.data)
Allow excluding services from live services count Adds a front end for: https://github.com/alphagov/notifications-api/pull/2417 > Sometimes we have to make a few services for what really is one > service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also > have our own test services which aren’t included in the count of live > services. We currently count these as one service by not including > them in the beta partners spreadsheet.
2019-03-25 14:46:42 +00:00
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-service-setting.html',
title="Count in list of live services",
form=form,
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/permissions/<permission>", methods=["GET", "POST"])
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
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
def service_set_permission(service_id, permission):
if permission not in PLATFORM_ADMIN_SERVICE_PERMISSIONS:
abort(404)
title = PLATFORM_ADMIN_SERVICE_PERMISSIONS[permission]['title']
form = ServiceOnOffSettingForm(
name=title,
enabled=current_service.has_permission(permission)
)
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
if form.validate_on_submit():
current_service.force_permission(permission, on=form.enabled.data)
Add email auth platform admin toggle also added tests to check visibility, url, and button content
2017-10-27 11:44:40 +01:00
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
return redirect(url_for(".service_settings", service_id=service_id))
return render_template(
'views/service-settings/set-service-setting.html',
title=title,
form=form,
)
Add button to toggle precompiled letters on/off
2018-02-21 17:41:19 +00:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/archive", methods=['GET', 'POST'])
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):
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
if not current_service.active and (
current_service.trial_mode or current_user.platform_admin
):
abort(403)
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)
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
flash(
'‘{}’ was deleted'.format(current_service.name),
'default_with_tick',
)
return redirect(url_for('.choose_account'))
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
else:
Let users archive their own trial mode services At the moment we have a blanket rule that users can’t archive their own services, to prevent someone accidentally deleting a real live service, because that would be Very Bad. But the tickets we get from users asking us to delete services are for services they set up when they were just trying out Notify. There’s not much harm in letting users delete these services, the consequences of doing so are much lower than those of deleting a live service. And it should mean fewer support tickets for us to deal with.
2019-05-29 16:51:25 +01:00
flash(
'Are you sure you want to delete ‘{}’? There’s no way to undo this.'.format(current_service.name),
'delete',
)
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 service_settings(service_id)
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/suspend", methods=["GET", "POST"])
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)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/resume", methods=["GET", "POST"])
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)
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
@main.route("/services/<uuid:service_id>/service-settings/send-files-by-email", methods=['GET', 'POST'])
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
@user_has_permissions('manage_service')
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
def send_files_by_email_contact_details(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()
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
contact_details = None
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
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
if contact_details:
contact_type = check_contact_details_type(contact_details)
field_to_update = getattr(form, contact_type)
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
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
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
Send files by email on for everyone and only depending on service having contact details set up. Display not set up yet for send files by email row when contact_link not set up
2020-02-25 11:27:43 +00:00
return render_template(
'views/service-settings/send-files-by-email.html', form=form, contact_details=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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-reply-to-email", methods=['GET'])
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))
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-reply-to", methods=['GET'])
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-reply-to/add", methods=['GET', 'POST'])
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
Save new reply-to email if test notification delivered Also check if it should be a default reply-to email address
2019-05-14 13:37:16 +01:00
is_default = first_email_address if first_email_address else form.is_default.data
Admin app settings to save reply to email address for service.
2016-05-16 13:09:58 +01:00
if form.validate_on_submit():
Deal with duplicate reply-to email addresses
2019-05-15 15:21:56 +01:00
try:
notification_id = service_api_client.verify_reply_to_email_address(
service_id, form.email_address.data
)["data"]["id"]
except HTTPError as e:
Tighten check for reply to address conflict error The check was made more permissive temporarily as we were changing error code we are returning form API from 400 to 409.
2020-04-02 12:11:14 +01:00
if e.status_code == 409:
Accept 409 conflict response code when reply-to address already exists Also stop checking error message.
2020-03-30 17:11:31 +01:00
flash(e.message, 'error')
Deal with duplicate reply-to email addresses
2019-05-15 15:21:56 +01:00
return redirect(url_for('.service_email_reply_to', service_id=service_id))
else:
raise e
Save new reply-to email if test notification delivered Also check if it should be a default reply-to email address
2019-05-14 13:37:16 +01:00
return redirect(url_for(
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
'.service_verify_reply_to_address',
Save new reply-to email if test notification delivered Also check if it should be a default reply-to email address
2019-05-14 13:37:16 +01:00
service_id=service_id,
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
notification_id=notification_id,
is_default=is_default
))
Save new reply-to email if test notification delivered Also check if it should be a default reply-to email address
2019-05-14 13:37:16 +01:00
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
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
flake8
2019-11-29 13:03:23 +00:00
@main.route(
"/services/<uuid:service_id>/service-settings/email-reply-to/<uuid:notification_id>/verify",
methods=['GET', 'POST']
)
Send request to api to check if reply-to address is working
2019-05-09 17:55:10 +01:00
@user_has_permissions('manage_service')
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
def service_verify_reply_to_address(service_id, notification_id):
Ensure that when updating reply-to email address old address is replaced Also fix tests
2019-05-20 18:05:55 +01:00
replace = request.args.get('replace', False)
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
is_default = request.args.get('is_default', False)
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
return render_template(
'views/service-settings/email-reply-to/verify.html',
service_id=service_id,
notification_id=notification_id,
Change content for email reply-to verification journey Earlier commits used placeholder content while awaiting official content.
2019-05-20 14:21:57 +01:00
partials=get_service_verify_reply_to_address_partials(service_id, notification_id),
Ensure that when updating reply-to email address old address is replaced Also fix tests
2019-05-20 18:05:55 +01:00
verb=("Change" if replace else "Add"),
Different back links and form actions on verify page depending if add or change
2019-05-21 13:10:17 +01:00
replace=replace,
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
is_default=is_default
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-reply-to/<uuid:notification_id>/verify.json")
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
@user_has_permissions('manage_service')
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
def service_verify_reply_to_address_updates(service_id, notification_id):
return jsonify(**get_service_verify_reply_to_address_partials(service_id, notification_id))
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
def get_service_verify_reply_to_address_partials(service_id, notification_id):
Stop AJAX when success or failure and show form on failure AJAX requests stop on success or failure, as the waiting page does not have to referesh any longer. Also on failure a form that allows user to try again is shown.
2019-05-20 17:32:40 +01:00
form = ServiceReplyToEmailForm()
first_email_address = current_service.count_email_reply_to_addresses == 0
Waiting page shows correct messages
2019-05-13 10:17:20 +01:00
notification = notification_api_client.get_notification(current_app.config["NOTIFY_SERVICE_ID"], notification_id)
Different back links and form actions on verify page depending if add or change
2019-05-21 13:10:17 +01:00
replace = request.args.get('replace', False)
Fix logic for showing and hiding checkbox The ‘make this default’ checkbox should be shown, except when: - the user is adding their first email reply to address (because the first one has to be the default) - they’re editing the existing default (because they can’t change it to be not default)
2019-06-05 16:32:08 +01:00
replace = False if replace == "False" else replace
existing_is_default = False
if replace:
existing = current_service.get_email_reply_to_address(replace)
existing_is_default = existing['is_default']
Waiting page shows correct messages
2019-05-13 10:17:20 +01:00
verification_status = "pending"
Stop AJAX when success or failure and show form on failure AJAX requests stop on success or failure, as the waiting page does not have to referesh any longer. Also on failure a form that allows user to try again is shown.
2019-05-20 17:32:40 +01:00
is_default = True if (request.args.get('is_default', False) == "True") else False
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
if notification["status"] in DELIVERED_STATUSES:
Waiting page shows correct messages
2019-05-13 10:17:20 +01:00
verification_status = "success"
Deal with duplicate reply-to email addresses
2019-05-15 15:21:56 +01:00
if notification["to"] not in [i["email_address"] for i in current_service.email_reply_to_addresses]:
Fix logic for showing and hiding checkbox The ‘make this default’ checkbox should be shown, except when: - the user is adding their first email reply to address (because the first one has to be the default) - they’re editing the existing default (because they can’t change it to be not default)
2019-06-05 16:32:08 +01:00
if replace:
Ensure that when updating reply-to email address old address is replaced Also fix tests
2019-05-20 18:05:55 +01:00
service_api_client.update_reply_to_email_address(
current_service.id, replace, email_address=notification["to"], is_default=is_default
)
else:
service_api_client.add_reply_to_email_address(
current_service.id,
email_address=notification["to"],
is_default=is_default
)
Use utils function to parse datetime strings Rather than hard-coding a format string in a bunch of different places we can use the function we already have in utils. This commit also refactors some logic around password resets to put the date-parsing changes in the most sensible bit of the codebase, so it’s clearer what the intention of the view-layer code is.
2020-01-21 12:23:30 +00:00
seconds_since_sending = (
utc_string_to_aware_gmt_datetime(datetime.utcnow().isoformat()) -
utc_string_to_aware_gmt_datetime(notification['created_at'])
).seconds
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
if notification["status"] in FAILURE_STATUSES or (
increase reply to address validation timeout on preview Celery/SQS underperforms in low-traffic environments. Tasks will sit on celery queues for several seconds before getting picked up if they're the only thing on the queue. This is observable in our test environments like preview and staging, but we've got enough load on production that this isn't an issue. When we validate reply to email addresses, we expect a delivery receipt to have been processed within 45 seconds of the button being pressed. On preview, we often observe times over that, possibly due to the several queues involved in sending an email and processing its receipt. So, to ensure that functional tests can pass (when we don't really care how fast things are, just that the flow doesn't break), bump this timeout up to 120 seconds on preview. The functional tests were waiting for 120 seconds for the reply to address to be validated anyway.
2020-01-07 11:57:38 +00:00
notification["status"] in SENDING_STATUSES and
seconds_since_sending > current_app.config['REPLY_TO_EMAIL_ADDRESS_VALIDATION_TIMEOUT']
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
):
Waiting page shows correct messages
2019-05-13 10:17:20 +01:00
verification_status = "failure"
Stop AJAX when success or failure and show form on failure AJAX requests stop on success or failure, as the waiting page does not have to referesh any longer. Also on failure a form that allows user to try again is shown.
2019-05-20 17:32:40 +01:00
form.email_address.data = notification['to']
form.is_default.data = is_default
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
return {
'status': render_template(
'views/service-settings/email-reply-to/_verify-updates.html',
reply_to_email_address=notification["to"],
service_id=current_service.id,
notification_id=notification_id,
verification_status=verification_status,
is_default=is_default,
Fix logic for showing and hiding checkbox The ‘make this default’ checkbox should be shown, except when: - the user is adding their first email reply to address (because the first one has to be the default) - they’re editing the existing default (because they can’t change it to be not default)
2019-06-05 16:32:08 +01:00
existing_is_default=existing_is_default,
Stop AJAX when success or failure and show form on failure AJAX requests stop on success or failure, as the waiting page does not have to referesh any longer. Also on failure a form that allows user to try again is shown.
2019-05-20 17:32:40 +01:00
form=form,
Different back links and form actions on verify page depending if add or change
2019-05-21 13:10:17 +01:00
first_email_address=first_email_address,
replace=replace
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
),
Stop AJAX when success or failure and show form on failure AJAX requests stop on success or failure, as the waiting page does not have to referesh any longer. Also on failure a form that allows user to try again is shown.
2019-05-20 17:32:40 +01:00
'stop': 0 if verification_status == "pending" else 1
Use ajax to auto-refresh reply-to email verifiaction page
2019-05-14 17:53:00 +01:00
}
Send request to api to check if reply-to address is working
2019-05-09 17:55:10 +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(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/email-reply-to/<uuid:reply_to_email_id>/edit",
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
methods=['GET', 'POST'],
endpoint="service_edit_email_reply_to"
)
@main.route(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/email-reply-to/<uuid:reply_to_email_id>/delete",
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
methods=['GET'],
endpoint="service_confirm_delete_email_reply_to"
)
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():
Do not verify email when updated email address did not change
2019-05-23 14:40:18 +01:00
if form.email_address.data == reply_to_email_address["email_address"]:
service_api_client.update_reply_to_email_address(
current_service.id,
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))
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
try:
notification_id = service_api_client.verify_reply_to_email_address(
service_id, form.email_address.data
)["data"]["id"]
except HTTPError as e:
Tighten check for reply to address conflict error The check was made more permissive temporarily as we were changing error code we are returning form API from 400 to 409.
2020-04-02 12:11:14 +01:00
if e.status_code == 409:
Accept 409 conflict response code when reply-to address already exists Also stop checking error message.
2020-03-30 17:11:31 +01:00
flash(e.message, 'error')
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
return redirect(url_for('.service_email_reply_to', service_id=service_id))
else:
raise e
return redirect(url_for(
'.service_verify_reply_to_address',
service_id=service_id,
Code refactor, details below: Apply suggestions from code review Reduce max verification waiting time to 90 seconds Also minor changes following peer review Co-Authored-By: Chris Hill-Scott <me@quis.cc> Use constants for notification status collections on verify reply-to email address Use a cleaner way of adding request arguments to url_for()
2019-05-21 16:08:50 +01:00
notification_id=notification_id,
is_default=True if reply_to_email_address['is_default'] else form.is_default.data,
replace=reply_to_email_id
Ensure that when updating reply-to email address old address is replaced Also fix tests
2019-05-20 18:05:55 +01:00
))
Verify email address when editing reply-to address Also fix the tests
2019-05-16 17:05:55 +01:00
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"):
Updated 'reply-to email address'
2019-07-09 16:42:38 +01:00
flash("Are you sure you want to delete this reply-to email 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,
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route(
"/services/<uuid:service_id>/service-settings/email-reply-to/<uuid:reply_to_email_id>/delete",
methods=['POST']
)
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
@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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-inbound-number", methods=['GET', 'POST'])
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
)
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
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.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))
Replace platform admin service setting buttons with forms Most of the existing platform admin buttons on the service settings page used to issue GET requests to switch service settings. This means they weren't protected by CSRF. On top of that as our number of service permissions increases over time a lot of buttons on the page made it hard to work with. To fix these issues we replace most of the buttons with rows in the platform admin settings table. Each setting has a 'Change' link that leads to a page with an On/Off switch form. This removes "research mode" switch completely since we're planning to deprecate it in the future and we don't expect to switch any new services into research mode at the moment. Most service permissions are now handled by a shared endpoint that is parameterized with the permission name. Some permissions that require some additional logic before they can be toggled (like document upload, which requires setting a contact address) have separate initial endpoints that redirect to `set_service_permission`. "Archive", "Suspend" and "Resume" actions are kept as buttons since they display a confirmation banner (which is a CSRF-protected form) and they're not easily represented as an On/Off switch.
2019-02-18 16:56:43 +00:00
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/sms-prefix", methods=['GET', 'POST'])
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-international-sms", methods=['GET', 'POST'])
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-inbound-sms", methods=['GET'])
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',
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-letters", methods=['GET'])
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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-<channel>", methods=['GET', 'POST'])
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
@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,
Add a new boolean radios fields and change forms to use it This adds a new OnOffField class that implements a boolean field that is rendered as two On / Off radio buttons. This allows us to avoid comparing 'on' and 'off' string values in the views since the field takes care of transforming form data into python booleans. This also adds a form class that can be used for any single On / Off switch forms (e.g. service permissions).
2019-02-18 16:27:53 +00:00
enabled=current_service.has_permission(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
)
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,
Add a new boolean radios fields and change forms to use it This adds a new OnOffField class that implements a boolean field that is rendered as two On / Off radio buttons. This allows us to avoid comparing 'on' and 'off' string values in the views since the field takes care of transforming form data into python booleans. This also adds a form class that can be used for any single On / Off switch forms (e.g. service permissions).
2019-02-18 16:27:53 +00:00
on=form.enabled.data,
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
)
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-auth-type", methods=['GET'])
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',
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/letter-contacts", methods=['GET'])
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)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/letter-contact/add", methods=['GET', 'POST'])
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
Refactor back link into view layer
2019-07-08 11:31:55 +01:00
from_template = request.args.get('from_template')
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
if form.validate_on_submit():
Apply sender to template when adding If you’ve come from a template to add a new letter sender then it’s because you want those words on that template. This commit adds the extra API call to make that happen.
2019-07-08 11:20:28 +01:00
new_letter_contact = 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
)
Apply sender to template when adding If you’ve come from a template to add a new letter sender then it’s because you want those words on that template. This commit adds the extra API call to make that happen.
2019-07-08 11:20:28 +01:00
if from_template:
service_api_client.update_service_template_sender(
service_id,
from_template,
new_letter_contact['data']['id'],
)
Allow letter templates to select the default contact block from the list
2018-01-03 10:44:36 +00:00
return redirect(
Apply sender to template when adding If you’ve come from a template to add a new letter sender then it’s because you want those words on that template. This commit adds the extra API call to make that happen.
2019-07-08 11:20:28 +01:00
url_for('.view_template', service_id=service_id, template_id=from_template)
Allow letter templates to select the default contact block from the list
2018-01-03 10:44:36 +00:00
)
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,
Refactor back link into view layer
2019-07-08 11:31:55 +01:00
back_link=(
url_for('main.view_template', template_id=from_template, service_id=current_service.id)
if from_template
else url_for('.service_letter_contact_details', service_id=current_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
)
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
@main.route(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/letter-contact/<uuid:letter_contact_id>/edit",
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
methods=['GET', 'POST'],
endpoint="service_edit_letter_contact",
)
@main.route(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/letter-contact/<uuid:letter_contact_id>/delete",
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
methods=['GET'],
endpoint="service_confirm_delete_letter_contact",
)
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():
Allow deleting default letter contact blocks It’s possible to delete default letter contact blocks because there is a fallback – having a blank letter contact block. This is different to SMS senders and reply to addresses. For this to make sense it also means: - adding the ‘blank’ letter contact block to the list of letter contact blocks - having a way of setting the default back to being blank
2019-07-05 13:17:48 +01:00
current_service.edit_letter_contact_block(
id=letter_contact_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,
Allow deleting default letter contact blocks It’s possible to delete default letter contact blocks because there is a fallback – having a blank letter contact block. This is different to SMS senders and reply to addresses. For this to make sense it also means: - adding the ‘blank’ letter contact block to the list of letter contact blocks - having a way of setting the default back to being blank
2019-07-05 13:17:48 +01:00
is_default=letter_contact_block['is_default'] or form.is_default.data
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))
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
if (request.endpoint == "main.service_confirm_delete_letter_contact"):
flash("Are you sure you want to delete this contact block?", 'delete')
Add multiple letter contact blocks for services from Admin app
2017-10-05 15:47:12 +01:00
return render_template(
'views/service-settings/letter-contact/edit.html',
form=form,
letter_contact_id=letter_contact_block['id'])
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/letter-contact/make-blank-default")
Allow deleting default letter contact blocks It’s possible to delete default letter contact blocks because there is a fallback – having a blank letter contact block. This is different to SMS senders and reply to addresses. For this to make sense it also means: - adding the ‘blank’ letter contact block to the list of letter contact blocks - having a way of setting the default back to being blank
2019-07-05 13:17:48 +01:00
@user_has_permissions('manage_service')
def service_make_blank_default_letter_contact(service_id):
current_service.remove_default_letter_contact_block()
return redirect(url_for('.service_letter_contact_details', service_id=service_id))
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
@main.route(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/letter-contact/<uuid:letter_contact_id>/delete",
Let users delete letter contact blocks Because they can delete email reply to addresses and text message senders.
2019-07-04 16:11:19 +01:00
methods=['POST'],
)
@user_has_permissions('manage_service')
def service_delete_letter_contact(service_id, letter_contact_id):
service_api_client.delete_letter_contact(
service_id=current_service.id,
letter_contact_id=letter_contact_id,
)
return redirect(url_for('.service_letter_contact_details', service_id=current_service.id))
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/sms-sender", methods=['GET'])
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',
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/sms-sender/add", methods=['GET', 'POST'])
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(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/sms-sender/<uuid:sms_sender_id>/edit",
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
methods=['GET', 'POST'],
endpoint="service_edit_sms_sender"
)
@main.route(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/sms-sender/<uuid:sms_sender_id>/delete",
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
methods=['GET'],
endpoint="service_confirm_delete_sms_sender"
)
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(
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
"/services/<uuid:service_id>/service-settings/sms-sender/<uuid:sms_sender_id>/delete",
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
methods=['POST'],
)
@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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-letter-contact-block", methods=['GET', 'POST'])
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-free-sms-allowance", methods=['GET', 'POST'])
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,
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-email-branding", methods=['GET', 'POST'])
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
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
form = SetEmailBranding(
rename branding to email_branding to help transition to having letter branding as well
2019-02-01 16:31:34 +00:00
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/preview-email-branding", methods=['GET', 'POST'])
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
@user_is_platform_admin
def service_preview_email_branding(service_id):
branding_style = request.args.get('branding_style', None)
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
form = PreviewBranding(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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/set-letter-branding", methods=['GET', 'POST'])
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
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
form = SetLetterBranding(
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
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
Show letter branding preview when selecting a brand This adds a preview pane which is visible when updating a letter brand. If JavaScript is enabled, the preview pane shows on the set-letter-branding page, and submitting the form saves updates the letter brand for a service immediately. If Javascript is not enabled, there is a separate 'Preview email branding' page which shows a preview of the brand and has a 'Save' button on it.
2019-02-15 14:47:39 +00:00
if form.validate_on_submit():
return redirect(url_for(
'.service_preview_letter_branding',
service_id=service_id,
branding_style=form.branding_style.data,
))
return render_template(
'views/service-settings/set-letter-branding.html',
form=form,
search_form=SearchByNameForm()
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/preview-letter-branding", methods=['GET', 'POST'])
Show letter branding preview when selecting a brand This adds a preview pane which is visible when updating a letter brand. If JavaScript is enabled, the preview pane shows on the set-letter-branding page, and submitting the form saves updates the letter brand for a service immediately. If Javascript is not enabled, there is a separate 'Preview email branding' page which shows a preview of the brand and has a 'Save' button on it.
2019-02-15 14:47:39 +00:00
@user_is_platform_admin
def service_preview_letter_branding(service_id):
branding_style = request.args.get('branding_style')
Allow editing of an organisation’s details Adds a user interface for updating all the columns added in https://github.com/alphagov/notifications-api/pull/2368 Sorry for the mega commit 😓
2019-02-19 17:26:16 +00:00
form = PreviewBranding(branding_style=branding_style)
Show letter branding preview when selecting a brand This adds a preview pane which is visible when updating a letter brand. If JavaScript is enabled, the preview pane shows on the set-letter-branding page, and submitting the form saves updates the letter brand for a service immediately. If Javascript is not enabled, there is a separate 'Preview email branding' page which shows a preview of the brand and has a 'Save' button on it.
2019-02-15 14:47:39 +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(
Show letter branding preview when selecting a brand This adds a preview pane which is visible when updating a letter brand. If JavaScript is enabled, the preview pane shows on the set-letter-branding page, and submitting the form saves updates the letter brand for a service immediately. If Javascript is not enabled, there is a separate 'Preview email branding' page which shows a preview of the brand and has a 'Save' button on it.
2019-02-15 14:47:39 +00:00
'views/service-settings/preview-letter-branding.html',
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
form=form,
Show letter branding preview when selecting a brand This adds a preview pane which is visible when updating a letter brand. If JavaScript is enabled, the preview pane shows on the set-letter-branding page, and submitting the form saves updates the letter brand for a service immediately. If Javascript is not enabled, there is a separate 'Preview email branding' page which shows a preview of the brand and has a 'Save' button on it.
2019-02-15 14:47:39 +00:00
service_id=service_id,
action=url_for('main.service_preview_letter_branding', service_id=service_id),
Add platform admin setting for letter branding Does two main things: - defines what ‘brands’ we support, in terms of the ID that DVLA use - adds a form to choose which branding a service uses (currently platform admin only, like email branding) By doing this we will be able to (with some more work) preview and send letters with a variety of different branding. Story: https://www.pivotaltracker.com/story/show/143506905
2017-04-19 16:11:28 +01:00
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/service-settings/link-service-to-organisation", methods=['GET', 'POST'])
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):
move to model based code layout
2019-05-23 17:17:26 +01:00
all_organisations = organisations_client.get_organisations()
link-services-to-organisations
2018-02-12 09:26:13 +00:00
form = LinkOrganisationsForm(
move to model based code layout
2019-05-23 17:17:26 +01:00
choices=convert_dictionary_to_wtforms_choices_format(all_organisations, 'id', 'name'),
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
organisations=current_service.organisation_id
link-services-to-organisations
2018-02-12 09:26:13 +00:00
)
if form.validate_on_submit():
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
if form.organisations.data != current_service.organisation_id:
link-services-to-organisations
2018-02-12 09:26:13 +00:00
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',
move to model based code layout
2019-05-23 17:17:26 +01:00
has_organisations=all_organisations,
link-services-to-organisations
2018-02-12 09:26:13 +00:00
form=form,
Add sticky footer and search on set service org This page can be really long. These things help navigate it quicker.
2019-07-16 16:52:19 +01:00
search_form=SearchByNameForm(),
link-services-to-organisations
2018-02-12 09:26:13 +00:00
)
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
@main.route("/services/<uuid:service_id>/branding-request/<branding_type>", methods=['GET', 'POST'])
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
@user_has_permissions('manage_service')
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
def branding_request(service_id, branding_type):
form = BrandingOptions(current_service, branding_type=branding_type)
Redirect to template after succesful branding request if user entered branding request flow from a template.
2020-01-23 15:54:13 +00:00
from_template = request.args.get('from_template')
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
if branding_type == "email":
branding_name = current_service.email_branding_name
elif branding_type == "letter":
branding_name = current_service.letter_branding_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
if form.validate_on_submit():
zendesk_client.create_ticket(
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
subject='{} branding request - {}'.format(branding_type.capitalize(), 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=(
Put current email branding in new branding request When we get a request for new branding it’s helpful to quickly see what the service’s current branding is, so we can get a better sense of why they want to change it.
2019-03-06 15:27:43 +00:00
'Organisation: {organisation}\n'
'Service: {service_name}\n'
'{dashboard_url}\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---'
Put current email branding in new branding request When we get a request for new branding it’s helpful to quickly see what the service’s current branding is, so we can get a better sense of why they want to change it.
2019-03-06 15:27:43 +00:00
'\nCurrent branding: {current_branding}'
'\nBranding requested: {branding_requested}'
Allow elaboration when ‘something else’ is chosen Letting people input a bit of free text should reduce the amount of back and forth we have to do over support tickets when setting up someone’s branding. If something else is the only option then we don’t show the radio button at all and have just the free text input on the page (not behind a progressive disclosure).
2019-09-12 14:33:11 +01:00
'{new_paragraph}'
'{detail}'
'\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
).format(
Remove dependence on domains.yml from settings Settings looked at `domains.yml` when users were making go live requests or email branding requests. This will allow us to remove the `domains.yml` file, by using information about organisations that is now stored in the database instead.
2019-04-04 11:23:40 +01:00
organisation=current_service.organisation.as_info_for_branding_request(current_user.email_domain),
Put current email branding in new branding request When we get a request for new branding it’s helpful to quickly see what the service’s current branding is, so we can get a better sense of why they want to change it.
2019-03-06 15:27:43 +00:00
service_name=current_service.name,
dashboard_url=url_for('main.service_dashboard', service_id=current_service.id, _external=True),
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
current_branding=branding_name,
Only show relevant choices of email branding Users who work in local government can’t have GOV.UK branding on their emails. And only those working for Companies House (for example) can request the Companies House branding. This commit adds: - new choices of email branding, which offer the name of the branding, rather than the style - logic to filter this list to only the applicable options, based on what we know about the user, service and organisation This is a change from the previous approach which put the onus on users to figure out the style of branding they wanted, when we might already know that a lot of the options weren’t available to them, or would be inconsistent with the branding of other services in their organisation.
2019-09-12 13:45:35 +01:00
branding_requested=dict(form.options.choices)[form.options.data],
Allow elaboration when ‘something else’ is chosen Letting people input a bit of free text should reduce the amount of back and forth we have to do over support tickets when setting up someone’s branding. If something else is the only option then we don’t show the radio button at all and have just the free text input on the page (not behind a progressive disclosure).
2019-09-12 14:33:11 +01:00
new_paragraph='\n\n' if form.something_else.data else '',
detail=form.something_else.data or ''
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
),
ticket_type=zendesk_client.TYPE_QUESTION,
user_email=current_user.email_address,
user_name=current_user.name,
Update Zendesk tags to reflect new taxonomy Requests to go live and email branding requests come through to Zendesk with tags attached automatically. With the revised taxonomy some of these tags need to be updated, as summarised in this spreadsheet. In addition, `notify_action` tag has to be added in each of those cases. Old|New ---|--- `notify_request_to_go_live_complete`|`notify_go_live_complete` `notify_request_to_go_live_incomplete`|`notify_go_live_incomplete` `notify_action_add_branding`|`notify_branding` `notify_request_to_go_live_incomplete_mou`|`notify_go_live_incomplete_mou` `notify_request_to_go_live`|`notify_go_live` – https://docs.google.com/spreadsheets/d/1o5ATsFsVK8Qpj7x8QvxX-SfEuBZ75028GEySVcdBFYU/edit#gid=0 – https://www.pivotaltracker.com/story/show/169842970
2019-11-19 15:46:29 +00:00
tags=['notify_action', 'notify_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')
Redirect to template after succesful branding request if user entered branding request flow from a template.
2020-01-23 15:54:13 +00:00
return redirect(url_for(
'.view_template', service_id=current_service.id, template_id=from_template
) if from_template else url_for('.service_settings', service_id=current_service.id))
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
return render_template(
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
'views/service-settings/branding/branding-options.html',
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=form,
Create a letter branding request flow to match email branding request Test if service settings links to branding request page for letters Parametrize all branding tests so they also work for letter branding
2020-01-17 17:03:07 +00:00
branding_type=branding_type,
Delete old letter branding request page
2020-01-21 16:02:41 +00:00
branding_name=branding_name,
Redirect to template after succesful branding request if user entered branding request flow from a template.
2020-01-23 15:54:13 +00:00
from_template=from_template
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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid: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
@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
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/data-retention/add", methods=['GET', 'POST'])
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
@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
)
Require IDs to be UUIDs in URLS We mostly rely on the API returning a 404 to generate 404s for trying to get things with non-UUID IDs. This is fine, except our tests often mock these API calls. So it could look like everything is working fine, except the thing your passing in might never be a valid UUID, and thus would 404 in a non-test environment. So this commit: 1. uses the `uuid` URL converter everywhere there’s something that looks like an ID in a URL parameter 2. adds a test which automates checking for 1.
2019-11-04 11:07:55 +00:00
@main.route("/services/<uuid:service_id>/data-retention/<uuid:data_retention_id>/edit", methods=['GET', 'POST'])
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
@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'
Reference in New Issue Copy Permalink