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

1413 lines
52 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,
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
Create go-live support tickets using the new way The new way of creating support tickets can be seen in [notifications-utils](https://github.com/alphagov/notifications-utils/pull/899). This changes tickets created when making a request to go live to use the new way, while other tickets stay the same for now. The go live tags have been removed. Some of these had become unneccessary since you can't make the request to go live unless they are true (e.g. `notify_go_live_email_reply_to`). Others will always get added by a Zendesk macro when the ticket is replied to, so we don't need to add them here.
2021-09-16 11:17:45 +01:00
from notifications_utils.clients.zendesk.zendesk_client import (
NotifySupportTicket,
)
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,
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,
)
Add audit event for suspending a service This is particularly important for broadcast services, where a rogue service or platform admin could launch a DoS attack by suspending a service at a critical moment when it needs to send alerts.
2021-07-08 15:20:24 +01:00
from app.event_handlers import (
Audit when a service is archived ("deleted") This is similar to the previous commit. I've used the term 'archive' to match the rest of the code - services aren't ever truly deleted.
2021-07-08 15:30:31 +01:00
create_archive_service_event,
Add audit event for suspending a service This is particularly important for broadcast services, where a rogue service or platform admin could launch a DoS attack by suspending a service at a critical moment when it needs to send alerts.
2021-07-08 15:20:24 +01:00
create_broadcast_account_type_change_event,
Audit when a service is resumed This could also be an issue if the service can send broadcasts, so it's worth auditing who performed this action.
2021-07-12 16:00:16 +01:00
create_resume_service_event,
Add audit event for suspending a service This is particularly important for broadcast services, where a rogue service or platform admin could launch a DoS attack by suspending a service at a critical moment when it needs to send alerts.
2021-07-08 15:20:24 +01:00
create_suspend_service_event,
)
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
Extract formatters into their own module We have lots of functions for converting various types of data into strings to be displayed to the user somewhere. This commit collects all these functions into their own module, rather than having them cluttering up `app/__init__.py` or buried amongst various other things that have ended up in `app/utils.py`.
2021-01-06 12:12:01 +00:00
from app.formatters import email_safe
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 (
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
AdminBillingDetailsForm,
AdminNotesForm,
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
AdminPreviewBrandingForm,
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
AdminServiceAddDataRetentionForm,
AdminServiceEditDataRetentionForm,
AdminServiceInboundNumberForm,
AdminServiceMessageLimitForm,
AdminServiceRateLimitForm,
AdminServiceSMSAllowanceForm,
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
AdminSetEmailBrandingForm,
AdminSetLetterBrandingForm,
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
AdminSetOrganisationForm,
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
ChooseEmailBrandingForm,
ChooseLetterBrandingForm,
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,
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,
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
ServiceBroadcastAccountTypeForm,
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
ServiceBroadcastChannelForm,
ServiceBroadcastNetworkForm,
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,
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,
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,
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,
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
SomethingElseBrandingForm,
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
)
Extract user utility code into own module This provides more room for expansion, and reduces the amount of arbitrary code in the __init__.py file for the new package.
2021-06-09 13:19:05 +01:00
from app.utils import DELIVERED_STATUSES, FAILURE_STATUSES, SENDING_STATUSES
Move and clarify "NHS_BRANDING_ID" constant This is specific to email branding [^1]. Using the name to match the current branding is more error-prone. [^1]: https://github.com/alphagov/notifications-api/commit/a165f62b6054b3ee97c7de70ab1152d4dd37a07e
2022-03-22 17:20:02 +00:00
from app.utils.branding import NHS_EMAIL_BRANDING_ID
Use "get_email_choices" directly in branding view
2022-03-23 15:22:54 +00:00
from app.utils.branding import get_email_choices as get_email_branding_choices
Extract user utility code into own module This provides more room for expansion, and reduces the amount of arbitrary code in the __init__.py file for the new package.
2021-06-09 13:19:05 +01:00
from app.utils.user import (
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_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 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',
Link directly to email branding "something else" Previously we duplicated the "something else" email branding form on its own page and embedded in the choices form (if it was the only option). See [^1] for how this looks - it's inconsistent. This DRYs-up the "something else" form by bypassing the choices form when "something else" is the only option. I've also tweaked the "Back" button to be consistent with this behaviour. Making this change also simplifies the choices form, which we'll be adding pool options to shortly. I'd like to make the letters form consistent, but let's see how emails pan out first. Note that the choices form will now show a single radio button if "something else" is the only option. I think that's OK as nothing will link to the page, and the form still works. [^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
2022-03-02 15:36:28 +00:00
service_permissions=PLATFORM_ADMIN_SERVICE_PERMISSIONS,
Remove remaining uses of ChooseBrandingForm This was missed in a previous commit.
2022-03-22 16:38:51 +00:00
email_branding_options=ChooseEmailBrandingForm(current_service)
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
)
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):
Remove re-enter password step from rename service The original idea behind was to always ask users to re-enter their password any time: - we want them to be sure that they want to do what they’re about to do - we want to be sure it’s really the user trying to do the thing (and not someone malicious) In reality we: - removed this from the initial place it was added (a descendent of the ‘suspend service’ feature) - only ever added it to the ‘rename service’ feature So in reality it’s not a pattern we have persisted with. Arguably there are several things you can now do in the admin app without re-entering your password which are much more high consequence than changing the service name. Also, with browser autofill there’s a lot less chance that forcing someone to re-enter a password really gives much defence against an unatteneded laptop, for example. I also wonder whether we might get people to give better service names if we make the process of renaming the service less intimidating. So this commit removes the need to re-enter your password when renaming a service. Note that re-naming an organisation still has the same check, but I haven’t removed that too for the sake of keeping scope of the PR small.
2021-12-01 12:07:00 +00:00
form = RenameServiceForm(name=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
Remove re-enter password step from rename service The original idea behind was to always ask users to re-enter their password any time: - we want them to be sure that they want to do what they’re about to do - we want to be sure it’s really the user trying to do the thing (and not someone malicious) In reality we: - removed this from the initial place it was added (a descendent of the ‘suspend service’ feature) - only ever added it to the ‘rename service’ feature So in reality it’s not a pattern we have persisted with. Arguably there are several things you can now do in the admin app without re-entering your password which are much more high consequence than changing the service name. Also, with browser autofill there’s a lot less chance that forcing someone to re-enter a password really gives much defence against an unatteneded laptop, for example. I also wonder whether we might get people to give better service names if we make the process of renaming the service less intimidating. So this commit removes the need to re-enter your password when renaming a service. Note that re-naming an organisation still has the same check, but I haven’t removed that too for the sake of keeping scope of the PR small.
2021-12-01 12:07:00 +00:00
try:
current_service.update(
name=form.name.data,
email_from=email_safe(form.name.data),
)
except HTTPError as http_error:
if http_error.status_code == 400 and any(
name_error_message.startswith('Duplicate service name')
for name_error_message in http_error.message['name']
):
form.name.errors.append('This service name is already in use')
else:
raise http_error
else:
return redirect(url_for('.service_settings', service_id=service_id))
Added choose_service using services_dao.
2016-01-18 16:01:04 +00:00
Add variant page for service-settings/name Includes correction of class used for bulleted list.
2020-07-01 14:24:27 +01:00
if current_service.organisation_type == 'local':
return render_template(
'views/service-settings/name-local.html',
form=form,
)
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/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/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):
Stop live services requesting to go live Live services shouldn't be able to request to go live again. Once a service is live we remove the option to go live from the Settings page, but we still link to the page to request to go live from other places e.g. the 'Get started' page. As a result, we've seen some services make another request to go live when their service has already been live for months - this change will stop that from happening.
2020-11-05 16:45:54 +00:00
if current_service.live:
return render_template('views/service-settings/service-already-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
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):
Move support ticket template into its own folder In the future this could be a place to put other support ticket content, if we turn them into Jinja template
2021-10-15 09:18:53 +01:00
ticket_message = render_template('support-tickets/go-live-request.txt') + '\n'
Create go-live support tickets using the new way The new way of creating support tickets can be seen in [notifications-utils](https://github.com/alphagov/notifications-utils/pull/899). This changes tickets created when making a request to go live to use the new way, while other tickets stay the same for now. The go live tags have been removed. Some of these had become unneccessary since you can't make the request to go live unless they are true (e.g. `notify_go_live_email_reply_to`). Others will always get added by a Zendesk macro when the ticket is replied to, so we don't need to add them here.
2021-09-16 11:17:45 +01:00
ticket = NotifySupportTicket(
subject=f'Request to go live - {current_service.name}',
message=ticket_message,
ticket_type=NotifySupportTicket.TYPE_QUESTION,
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_name=current_user.name,
Create go-live support tickets using the new way The new way of creating support tickets can be seen in [notifications-utils](https://github.com/alphagov/notifications-utils/pull/899). This changes tickets created when making a request to go live to use the new way, while other tickets stay the same for now. The go live tags have been removed. Some of these had become unneccessary since you can't make the request to go live unless they are true (e.g. `notify_go_live_email_reply_to`). Others will always get added by a Zendesk macro when the ticket is replied to, so we don't need to add them here.
2021-09-16 11:17:45 +01:00
user_email=current_user.email_address,
Hide details of go live request ticket from the user We put some content in the go live ticket which is for our benefit, for example notes about the organisation. It’s hard for us to be able to say what we want here if we know that the person making a go live request is going to see those notes. This commit changes go live requests so that the initial content of the ticket is hidden from the person raising it (in Zendesk it will appear as an ‘internal note’, rather than a ‘public reply’). --- Depends on: - [ ] https://github.com/alphagov/notifications-utils/pull/877/files
2021-07-05 11:49:22 +01:00
requester_sees_message_content=False,
Create go-live support tickets using the new way The new way of creating support tickets can be seen in [notifications-utils](https://github.com/alphagov/notifications-utils/pull/899). This changes tickets created when making a request to go live to use the new way, while other tickets stay the same for now. The go live tags have been removed. Some of these had become unneccessary since you can't make the request to go live unless they are true (e.g. `notify_go_live_email_reply_to`). Others will always get added by a Zendesk macro when the ticket is replied to, so we don't need to add them here.
2021-09-16 11:17:45 +01:00
org_id=current_service.organisation_id,
org_type=current_service.organisation_type,
service_id=current_service.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
)
Create go-live support tickets using the new way The new way of creating support tickets can be seen in [notifications-utils](https://github.com/alphagov/notifications-utils/pull/899). This changes tickets created when making a request to go live to use the new way, while other tickets stay the same for now. The go live tags have been removed. Some of these had become unneccessary since you can't make the request to go live unless they are true (e.g. `notify_go_live_email_reply_to`). Others will always get added by a Zendesk macro when the ticket is replied to, so we don't need to add them here.
2021-09-16 11:17:45 +01:00
zendesk_client.send_ticket_to_zendesk(ticket)
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
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
@main.route("/services/<uuid:service_id>/service-settings/broadcasts", methods=["GET", "POST"])
@user_is_platform_admin
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
def service_set_broadcast_channel(service_id):
Simplify channel selection using radio buttons This takes a similar approach as in the previous commit. Since the "training channel" doesn't really exist, we need some extra code to pre-select it if a service is already in training mode. As in the previous commit, I've removed a few non-critical test cases where we really don't need to test exhaustively. Note that we also need some specific code to avoid pre-selecting an option for non-broadcast services, which only used to work by fluke: we would try to populate the field with (False, None, 'all'), which isn't a valid combination, so nothing was selected.
2021-06-07 17:23:48 +01:00
if current_service.has_permission('broadcast'):
if current_service.live:
channel = current_service.broadcast_channel
else:
channel = 'training'
else:
channel = None
form = ServiceBroadcastChannelForm(channel=channel)
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
if form.validate_on_submit():
Simplify channel selection using radio buttons This takes a similar approach as in the previous commit. Since the "training channel" doesn't really exist, we need some extra code to pre-select it if a service is already in training mode. As in the previous commit, I've removed a few non-critical test cases where we really don't need to test exhaustively. Note that we also need some specific code to avoid pre-selecting an option for non-broadcast services, which only used to work by fluke: we would try to populate the field with (False, None, 'all'), which isn't a valid combination, so nothing was selected.
2021-06-07 17:23:48 +01:00
if form.channel.data == 'training':
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
return redirect(url_for(
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
'.service_confirm_broadcast_account_type',
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
service_id=current_service.id,
Simplify channel selection using radio buttons This takes a similar approach as in the previous commit. Since the "training channel" doesn't really exist, we need some extra code to pre-select it if a service is already in training mode. As in the previous commit, I've removed a few non-critical test cases where we really don't need to test exhaustively. Note that we also need some specific code to avoid pre-selecting an option for non-broadcast services, which only used to work by fluke: we would try to populate the field with (False, None, 'all'), which isn't a valid combination, so nothing was selected.
2021-06-07 17:23:48 +01:00
account_type='training-test-all'
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
))
return redirect(url_for(
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
'.service_set_broadcast_network',
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
service_id=current_service.id,
Simplify channel selection using radio buttons This takes a similar approach as in the previous commit. Since the "training channel" doesn't really exist, we need some extra code to pre-select it if a service is already in training mode. As in the previous commit, I've removed a few non-critical test cases where we really don't need to test exhaustively. Note that we also need some specific code to avoid pre-selecting an option for non-broadcast services, which only used to work by fluke: we would try to populate the field with (False, None, 'all'), which isn't a valid combination, so nothing was selected.
2021-06-07 17:23:48 +01:00
broadcast_channel=form.channel.data,
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
))
return render_template(
'views/service-settings/service-set-broadcast-channel.html',
form=form,
)
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
@main.route("/services/<uuid:service_id>/service-settings/broadcasts/<broadcast_channel>", methods=["GET", "POST"])
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
@user_is_platform_admin
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
def service_set_broadcast_network(service_id, broadcast_channel):
# only populate old settings when the channel is unchanged
if current_service.broadcast_channel == broadcast_channel:
Simplify network choice form to use boolean radio This follows the same pattern as in other forms [1]. [1]: https://github.com/alphagov/notifications-admin/blob/1b459d66927718937e0f890c6ca00524ebee8035/app/templates/views/organisations/add-gp-organisation.html#L20
2021-06-07 16:52:36 +01:00
provider = current_service.allowed_broadcast_provider
Simplify network choice to optional radio buttons Previously this field had to mimic the final hyphenated string of the broadcast account type, even though it was only used to select one of its components. The new, shorter choices make it easier to simplify the test for the POST request. I've also deleted a number of test cases for pre-selected radios. This functionality isn't critical, so we don't need to exhaustively test every single possible combination of values.
2021-06-07 17:06:15 +01:00
form = ServiceBroadcastNetworkForm(
broadcast_channel=broadcast_channel,
all_networks=provider == 'all',
network=provider if provider != 'all' else None,
)
Add conditional reveal to network selection Rather than try to explain all/only just through words we can use some interaction design to make the hierarchy of choices more explicit.
2021-05-11 12:39:52 +01:00
else:
form = ServiceBroadcastNetworkForm(
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
broadcast_channel=broadcast_channel
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
)
Add confirmation step to emergency alert settings It feels quite dangerous that it’s just one click to make an emergency alerts service live. This commit adds a confirmation step which explains the consequences of what you’re about to do.
2021-05-10 22:00:09 +01:00
if form.validate_on_submit():
return redirect(url_for(
'.service_confirm_broadcast_account_type',
service_id=current_service.id,
Add property to construct account type string This allows us to start decoupling the form fields from the final, hyphenated string, which we'll do in the next commits. Note that I've also removed the conditional that changes the data of the network field as part of validating it. We shouldn't change data in validations, and having the new property directly above makes it clear there's no need for this code.
2021-06-07 16:38:58 +01:00
account_type=form.account_type,
Add confirmation step to emergency alert settings It feels quite dangerous that it’s just one click to make an emergency alerts service live. This commit adds a confirmation step which explains the consequences of what you’re about to do.
2021-05-10 22:00:09 +01:00
))
return render_template(
Add a second step for choosing networks Only the test channel has the option to isolate messages to one network. This commits makes the choices less confusing by only showing the network choice to those who have selected the test channel.
2021-05-11 11:07:30 +01:00
'views/service-settings/service-set-broadcast-network.html',
Add confirmation step to emergency alert settings It feels quite dangerous that it’s just one click to make an emergency alerts service live. This commit adds a confirmation step which explains the consequences of what you’re about to do.
2021-05-10 22:00:09 +01:00
form=form,
)
@main.route(
Allow setting provider for any channel Previously we could only select a provider when using the test channel, but this is also required for others channels when we do tests on the production network with individual MNOs. In order to reduce duplication and improve consistency, I've reused the new broadcast_service_name_tag macro to show the setting.
2021-05-20 13:27:22 +01:00
"/services/<uuid:service_id>/service-settings/broadcasts/<account_type>/confirm",
Add confirmation step to emergency alert settings It feels quite dangerous that it’s just one click to make an emergency alerts service live. This commit adds a confirmation step which explains the consequences of what you’re about to do.
2021-05-10 22:00:09 +01:00
methods=["GET", "POST"]
)
@user_is_platform_admin
def service_confirm_broadcast_account_type(service_id, account_type):
form = ServiceBroadcastAccountTypeForm(account_type=account_type)
form.validate()
if form.account_type.errors:
abort(404)
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
if form.validate_on_submit():
Clear user cache when broadcast service settings form is submitted When the broadcast service settings form is submitted it now removes all permissions for users in notifications-api. This means it should be clearing the user cache.
2021-07-13 17:06:35 +01:00
cached_service_user_ids = [user.id for user in current_service.active_users]
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
service_api_client.set_service_broadcast_settings(
current_service.id,
service_mode=form.account_type.service_mode,
broadcast_channel=form.account_type.broadcast_channel,
Clear user cache when broadcast service settings form is submitted When the broadcast service settings form is submitted it now removes all permissions for users in notifications-api. This means it should be clearing the user cache.
2021-07-13 17:06:35 +01:00
provider_restriction=form.account_type.provider_restriction,
cached_service_user_ids=cached_service_user_ids
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
)
Add an audit event when a service's broadcast permissions change This adds an audit event to the `events` table when the broadcast permissions for a service (the service mode, channel or provider restriction) changes.
2021-03-04 12:09:28 +00:00
create_broadcast_account_type_change_event(
service_id=current_service.id,
changed_by_id=current_user.id,
service_mode=form.account_type.service_mode,
broadcast_channel=form.account_type.broadcast_channel,
provider_restriction=form.account_type.provider_restriction,
)
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
return redirect(url_for(".service_settings", service_id=service_id))
return render_template(
Add confirmation step to emergency alert settings It feels quite dangerous that it’s just one click to make an emergency alerts service live. This commit adds a confirmation step which explains the consequences of what you’re about to do.
2021-05-10 22:00:09 +01:00
'views/service-settings/service-confirm-broadcast-account-type.html',
Add form to set service broadcast account type Note, no option at the moment to set the service broadcast account type as None, or back to without the broadcast permission. This has been done for speed of development given the chance of us needing this is very low. We can add it later if we need to.
2021-02-15 21:02:37 +00:00
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/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):
Fix and test archive service permissions Previously the backend would never validate permissions because the "not service.active" part would (usually) fail. I've updated it to match the (inverse of the) conditional we have in the HTML [1]. [1]: https://github.com/alphagov/notifications-admin/blob/6ac593aa5f176fe9dacb4be51ebda818bb9e8e1b/app/templates/views/service-settings.html#L455
2021-07-14 14:43:04 +01:00
if not current_service.active or not (
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
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':
Refactor archive to do one sync delete of all keys rather than many Otherwise we could be waiting on 50 sync calls to redis to happen. This way we do it in one sync call and follow the pattern of https://github.com/alphagov/notifications-admin/blob/b98f4561fabc00ed1e9abcedfdee29005cdf3e5d/app/notify_client/organisations_api_client.py#L56
2020-05-22 17:12:00 +01:00
# We need to purge the cache for the services users as otherwise, although they will have had their permissions
# removed in the DB, they would still have permissions in the cache to view/edit/manage this service
cached_service_user_ids = [user.id for user in current_service.active_users]
service_api_client.archive_service(service_id, cached_service_user_ids)
DRY-up and enforce kwargs for most events For most events this makes the purpose of each argument clearer at the point the event is called. It's still worth having a function for each event type, as this abstracts knowledge of the event label. Using a schema approach will make adding new events easier. In the next commit we'll DRY-up the duplication in the tests as well.
2021-07-12 15:29:53 +01:00
create_archive_service_event(service_id=service_id, archived_by_id=current_user.id)
Audit when a service is archived ("deleted") This is similar to the previous commit. I've used the term 'archive' to match the rest of the code - services aren't ever truly deleted.
2021-07-08 15:30:31 +01:00
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"])
Enforce only Platform Admin can suspend / resume This was previously out-of-sync with the superficial restriction in the HTML [1][2]. [1]: https://github.com/alphagov/notifications-admin/blob/6ac593aa5f176fe9dacb4be51ebda818bb9e8e1b/app/templates/views/service-settings.html#L462-L468 [2]: https://github.com/alphagov/notifications-admin/blob/6ac593aa5f176fe9dacb4be51ebda818bb9e8e1b/app/templates/views/service-settings.html#L471
2021-07-14 14:29:09 +01:00
@user_is_platform_admin
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)
DRY-up and enforce kwargs for most events For most events this makes the purpose of each argument clearer at the point the event is called. It's still worth having a function for each event type, as this abstracts knowledge of the event label. Using a schema approach will make adding new events easier. In the next commit we'll DRY-up the duplication in the tests as well.
2021-07-12 15:29:53 +01:00
create_suspend_service_event(service_id=service_id, suspended_by_id=current_user.id)
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
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"])
Enforce only Platform Admin can suspend / resume This was previously out-of-sync with the superficial restriction in the HTML [1][2]. [1]: https://github.com/alphagov/notifications-admin/blob/6ac593aa5f176fe9dacb4be51ebda818bb9e8e1b/app/templates/views/service-settings.html#L462-L468 [2]: https://github.com/alphagov/notifications-admin/blob/6ac593aa5f176fe9dacb4be51ebda818bb9e8e1b/app/templates/views/service-settings.html#L471
2021-07-14 14:29:09 +01:00
@user_is_platform_admin
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)
Audit when a service is resumed This could also be an issue if the service can send broadcasts, so it's worth auditing who performed this action.
2021-07-12 16:00:16 +01:00
create_resume_service_event(service_id=service_id, resumed_by_id=current_user.id)
Add Suspend and Resume service buttons to service-settings page.
2017-01-31 15:56:06 +00:00
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():
Let platform admins add or update service reply to email address without the need for verification. This is for when the email takes too long to arrive and the service users cannot update it as a result. A more streamlined solution has been proposed where we could send a link in the verification email to the users and clicking that link would add/update reply-email-to address. That would require a bit more work so right now I am proposing this as a quick stop gap so that we don't have to go to the database manually to add the reply-to email address.
2021-05-28 15:06:31 +01:00
if current_user.platform_admin:
service_api_client.add_reply_to_email_address(
service_id,
email_address=form.email_address.data,
is_default=is_default
)
return redirect(url_for('.service_email_reply_to', service_id=service_id))
else:
try:
notification_id = service_api_client.verify_reply_to_email_address(
service_id, form.email_address.data
)["data"]["id"]
except HTTPError as e:
if e.status_code == 409:
flash(e.message, 'error')
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,
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)
Fix bug with reply to email addresses https://www.pivotaltracker.com/story/show/180026726 There was a bug where if you enter an invalid email address in to the edit reply to email address form and click save, the form you get shown with your error message will always contain the field to set as default the reply to and also delete. This should not have been the case. If you make an error on the form when changing a reply to that is already a default, then you should not be given the chance to change it to not default, nor should you be able to delete it. This commit fixes that bug by making sure the additional form fields are only shown if the reply to being changed is not the default.
2021-11-04 11:21:58 +00:00
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']
Fix bug with reply to email addresses https://www.pivotaltracker.com/story/show/180026726 There was a bug where if you enter an invalid email address in to the edit reply to email address form and click save, the form you get shown with your error message will always contain the field to set as default the reply to and also delete. This should not have been the case. If you make an error on the form when changing a reply to that is already a default, then you should not be given the chance to change it to not default, nor should you be able to delete it. This commit fixes that bug by making sure the additional form fields are only shown if the reply to being changed is not the default.
2021-11-04 11:21:58 +00:00
show_choice_of_default_checkbox = not reply_to_email_address['is_default']
Allow user to add multiple reply-to addresses
2017-09-25 15:14:13 +01:00
if form.validate_on_submit():
Let platform admins add or update service reply to email address without the need for verification. This is for when the email takes too long to arrive and the service users cannot update it as a result. A more streamlined solution has been proposed where we could send a link in the verification email to the users and clicking that link would add/update reply-email-to address. That would require a bit more work so right now I am proposing this as a quick stop gap so that we don't have to go to the database manually to add the reply-to email address.
2021-05-28 15:06:31 +01:00
if form.email_address.data == reply_to_email_address["email_address"] or current_user.platform_admin:
Do not verify email when updated email address did not change
2019-05-23 14:40:18 +01:00
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,
Fix bug with reply to email addresses https://www.pivotaltracker.com/story/show/180026726 There was a bug where if you enter an invalid email address in to the edit reply to email address form and click save, the form you get shown with your error message will always contain the field to set as default the reply to and also delete. This should not have been the case. If you make an error on the form when changing a reply to that is already a default, then you should not be given the chance to change it to not default, nor should you be able to delete it. This commit fixes that bug by making sure the additional form fields are only shown if the reply to being changed is not the default.
2021-11-04 11:21:58 +00:00
show_choice_of_default_checkbox=show_choice_of_default_checkbox
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
)
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'] == []
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceInboundNumberForm(
Added Multiple SMS sender functionality
2017-10-24 15:37:44 +01:00
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):
Convert radios on SMS prefix page Includes changing form.enabled to use OnOffField, for consistency with other on/off fields. OnOffField's data is a boolean, not a string, so some of the logic using it needed to be changed.
2020-07-03 11:48:17 +01:00
form = SMSPrefixForm(enabled=current_service.prefix_sms)
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(
Convert radios on SMS prefix page Includes changing form.enabled to use OnOffField, for consistency with other on/off fields. OnOffField's data is a boolean, not a string, so some of the logic using it needed to be changed.
2020-07-03 11:48:17 +01:00
prefix_sms=form.enabled.data
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):
Refactor use ServiceOnOffForm We no longer need a custom form object here – ServiceOnOffForm does the same job of turning strings to booleans and back again.
2020-05-29 09:55:34 +01:00
form = ServiceOnOffSettingForm(
'Send text messages to international phone numbers',
enabled=current_service.has_permission('international_sms'),
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 use ServiceOnOffForm We no longer need a custom form object here – ServiceOnOffForm does the same job of turning strings to booleans and back again.
2020-05-29 09:55:34 +01:00
on=form.enabled.data,
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
)
Let users switch international letters on and off We’ve decided that this feature should be self-service, and on by default for all users. Before we can make it on by default we should give users a way to switch it off for themselves. Which is what this PR does.
2020-05-29 10:47:52 +01:00
@main.route("/services/<uuid:service_id>/service-settings/set-international-letters", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def service_set_international_letters(service_id):
form = ServiceOnOffSettingForm(
'Send letters to international addresses',
enabled=current_service.has_permission('international_letters'),
)
if form.validate_on_submit():
current_service.force_permission(
'international_letters',
on=form.enabled.data,
)
return redirect(
url_for(".service_settings", service_id=service_id)
)
return render_template(
'views/service-settings/set-international-letters.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-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)
Don’t let broadcast re-enable other channels When a service is switched over to broadcast it has the email, text message and letter permissions removed. And the links to switch these settings back on are hidden. This commit ensures that even if the user manually goes to the URLs for these pages, they still won’t be able to switch the other channels back on.
2020-07-13 09:04:53 +01:00
if current_service.has_permission('broadcast'):
abort(403)
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
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-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):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceSMSAllowanceForm(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,
)
Allow platform admins to change daily message limit One less thing we have to go into the database to do, and remember to manually clear the cache for after.
2020-10-19 17:19:32 +01:00
@main.route("/services/<uuid:service_id>/service-settings/set-message-limit", methods=['GET', 'POST'])
@user_is_platform_admin
def set_message_limit(service_id):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceMessageLimitForm(message_limit=current_service.message_limit)
Allow platform admins to change daily message limit One less thing we have to go into the database to do, and remember to manually clear the cache for after.
2020-10-19 17:19:32 +01:00
if form.validate_on_submit():
current_service.update(message_limit=form.message_limit.data)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-message-limit.html',
form=form,
)
Allow platform admins to change rate limit One less thing we have to go into the database to do, and remember to manually clear the cache for after.
2020-10-21 14:30:35 +01:00
@main.route("/services/<uuid:service_id>/service-settings/set-rate-limit", methods=['GET', 'POST'])
@user_is_platform_admin
def set_rate_limit(service_id):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceRateLimitForm(rate_limit=current_service.rate_limit)
Allow platform admins to change rate limit One less thing we have to go into the database to do, and remember to manually clear the cache for after.
2020-10-21 14:30:35 +01:00
if form.validate_on_submit():
current_service.update(rate_limit=form.rate_limit.data)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/set-rate-limit.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
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
form = AdminSetEmailBrandingForm(
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)
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
form = AdminPreviewBrandingForm(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
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
form = AdminSetLetterBrandingForm(
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')
Rename branding forms to clarify who they're for I've often struggled to find the form associated with a particular page due to the overlapping names e.g. "SetEmailBranding" sounds more like the radio button form a user sees than "BrandingOptions". Almost every form in forms.py also ends with "Form", so this also makes the branding forms consistent with that naming convention.
2022-03-03 11:40:03 +00:00
form = AdminPreviewBrandingForm(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
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminSetOrganisationForm(
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
)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
def create_email_branding_zendesk_ticket(form_option_selected, detail=None):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
form = ChooseEmailBrandingForm(current_service)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
ticket_message = render_template(
'support-tickets/branding-request.txt',
current_branding=current_service.email_branding_name,
branding_requested=dict(form.options.choices)[form_option_selected],
detail=detail,
)
ticket = NotifySupportTicket(
subject=f'Email branding request - {current_service.name}',
message=ticket_message,
ticket_type=NotifySupportTicket.TYPE_QUESTION,
user_name=current_user.name,
user_email=current_user.email_address,
org_id=current_service.organisation_id,
org_type=current_service.organisation_type,
service_id=current_service.id
)
zendesk_client.send_ticket_to_zendesk(ticket)
Change both existing branding URLs This changes the URLs for someone to request new email or letter branding to match the new URLs we've agreed for the new email branding changes. The old URLs are still in place for now too to keep backwards compatibility.
2022-02-02 16:44:32 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-branding", 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')
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
def email_branding_request(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
form = ChooseEmailBrandingForm(current_service)
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
branding_name = current_service.email_branding_name
if form.validate_on_submit():
Link directly to email branding "something else" Previously we duplicated the "something else" email branding form on its own page and embedded in the choices form (if it was the only option). See [^1] for how this looks - it's inconsistent. This DRYs-up the "something else" form by bypassing the choices form when "something else" is the only option. I've also tweaked the "Back" button to be consistent with this behaviour. Making this change also simplifies the choices form, which we'll be adding pool options to shortly. I'd like to make the letters form consistent, but let's see how emails pan out first. Note that the choices form will now show a single radio button if "something else" is the only option. I think that's OK as nothing will link to the page, and the form still works. [^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
2022-03-02 15:36:28 +00:00
return redirect(
url_for(
f'.email_branding_{form.options.data}',
service_id=current_service.id,
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
)
Link directly to email branding "something else" Previously we duplicated the "something else" email branding form on its own page and embedded in the choices form (if it was the only option). See [^1] for how this looks - it's inconsistent. This DRYs-up the "something else" form by bypassing the choices form when "something else" is the only option. I've also tweaked the "Back" button to be consistent with this behaviour. Making this change also simplifies the choices form, which we'll be adding pool options to shortly. I'd like to make the letters form consistent, but let's see how emails pan out first. Note that the choices form will now show a single radio button if "something else" is the only option. I think that's OK as nothing will link to the page, and the form still works. [^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
2022-03-02 15:36:28 +00:00
)
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
return render_template(
Split branding-options.html into two This splits the template into separate templates for emails and letters since the journey for email branding is about to change.
2022-01-19 16:26:57 +00:00
'views/service-settings/branding/email-branding-options.html',
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
form=form,
branding_name=branding_name,
)
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
def check_email_branding_allowed_for_service(branding):
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
allowed_branding_for_service = dict(
Use "get_email_choices" directly in branding view
2022-03-23 15:22:54 +00:00
get_email_branding_choices(current_service)
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
)
Use "get_email_choices" directly in branding view
2022-03-23 15:22:54 +00:00
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
if branding not in allowed_branding_for_service:
abort(404)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-branding/govuk", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def email_branding_govuk(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
check_email_branding_allowed_for_service('govuk')
Make separate endpoints for GOV.UK email branding options The endpoint to change the email branding to "GOV.UK" branding and "GOV.UK and organisation" branding was the same but with a query string used to determine which of the two options had been selected. This makes them two separate endpoints, which makes the code a bit simpler and hopefully means there is less chance of things not working as expected.
2022-02-03 11:31:25 +00:00
if request.method == 'POST':
NHS and GOV.UK email branding pages now show preview and apply branding The pages you were redirected to if you selected either GOV.UK branding or NHS branding used to give information about the branding and have a button that submitted a Zendesk ticket. Now, we show a preview of the new branding and the button applies it.
2022-02-22 11:37:40 +00:00
current_service.update(email_branding=None)
Make separate endpoints for GOV.UK email branding options The endpoint to change the email branding to "GOV.UK" branding and "GOV.UK and organisation" branding was the same but with a query string used to determine which of the two options had been selected. This makes them two separate endpoints, which makes the code a bit simpler and hopefully means there is less chance of things not working as expected.
2022-02-03 11:31:25 +00:00
NHS and GOV.UK email branding pages now show preview and apply branding The pages you were redirected to if you selected either GOV.UK branding or NHS branding used to give information about the branding and have a button that submitted a Zendesk ticket. Now, we show a preview of the new branding and the button applies it.
2022-02-22 11:37:40 +00:00
flash('You’ve updated your email branding', 'default')
Make separate endpoints for GOV.UK email branding options The endpoint to change the email branding to "GOV.UK" branding and "GOV.UK and organisation" branding was the same but with a query string used to determine which of the two options had been selected. This makes them two separate endpoints, which makes the code a bit simpler and hopefully means there is less chance of things not working as expected.
2022-02-03 11:31:25 +00:00
return redirect(url_for('.service_settings', service_id=current_service.id))
return render_template('views/service-settings/branding/email-branding-govuk.html')
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
Make separate endpoints for GOV.UK email branding options The endpoint to change the email branding to "GOV.UK" branding and "GOV.UK and organisation" branding was the same but with a query string used to determine which of the two options had been selected. This makes them two separate endpoints, which makes the code a bit simpler and hopefully means there is less chance of things not working as expected.
2022-02-03 11:31:25 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-branding/govuk-and-org", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def email_branding_govuk_and_org(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
check_email_branding_allowed_for_service('govuk_and_org')
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
if request.method == 'POST':
Split out the govuk and govuk_and_org branding templates The `.email_branding_govuk` and `.email_branding_govuk_and_org` routes shared a template since the content was the same - the only difference was in the action of the button. However, since the pages will no longer be so similar (e.g. the govuk page will show a preview) this splits them up to use separate templates. It may be the case that when the branding work is complete these pages are fairly similar and we decided that one template between the two endpoints is the best option again.
2022-02-17 14:52:24 +00:00
create_email_branding_zendesk_ticket('govuk_and_org')
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
flash('Thanks for your branding request. We’ll get back to you within one working day.', 'default')
return redirect(url_for('.service_settings', service_id=current_service.id))
Split out the govuk and govuk_and_org branding templates The `.email_branding_govuk` and `.email_branding_govuk_and_org` routes shared a template since the content was the same - the only difference was in the action of the button. However, since the pages will no longer be so similar (e.g. the govuk page will show a preview) this splits them up to use separate templates. It may be the case that when the branding work is complete these pages are fairly similar and we decided that one template between the two endpoints is the best option again.
2022-02-17 14:52:24 +00:00
return render_template('views/service-settings/branding/email-branding-govuk-org.html')
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-branding/nhs", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def email_branding_nhs(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
check_email_branding_allowed_for_service('nhs')
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
if request.method == 'POST':
Move and clarify "NHS_BRANDING_ID" constant This is specific to email branding [^1]. Using the name to match the current branding is more error-prone. [^1]: https://github.com/alphagov/notifications-api/commit/a165f62b6054b3ee97c7de70ab1152d4dd37a07e
2022-03-22 17:20:02 +00:00
current_service.update(email_branding=NHS_EMAIL_BRANDING_ID)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
NHS and GOV.UK email branding pages now show preview and apply branding The pages you were redirected to if you selected either GOV.UK branding or NHS branding used to give information about the branding and have a button that submitted a Zendesk ticket. Now, we show a preview of the new branding and the button applies it.
2022-02-22 11:37:40 +00:00
flash('You’ve updated your email branding', 'default')
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
return redirect(url_for('.service_settings', service_id=current_service.id))
Move and clarify "NHS_BRANDING_ID" constant This is specific to email branding [^1]. Using the name to match the current branding is more error-prone. [^1]: https://github.com/alphagov/notifications-api/commit/a165f62b6054b3ee97c7de70ab1152d4dd37a07e
2022-03-22 17:20:02 +00:00
return render_template(
'views/service-settings/branding/email-branding-nhs.html',
nhs_branding_id=NHS_EMAIL_BRANDING_ID
)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
@main.route("/services/<uuid:service_id>/service-settings/email-branding/organisation", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def email_branding_organisation(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
check_email_branding_allowed_for_service('organisation')
Only show branding description pages if branding allowed for service It shouldn't be possible to view the page to confirm that you want a particular type of email branding if that branding is not allowed for your service. Although we don't show banned branding options on the branding form, it would have been possible to visit the relevant URLs directly. We now give a `404` status page if you visit a page to select branding that isn't allowed.
2022-02-02 16:21:36 +00:00
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
if request.method == 'POST':
create_email_branding_zendesk_ticket('organisation')
flash('Thanks for your branding request. We’ll get back to you within one working day.', 'default')
return redirect(url_for('.service_settings', service_id=current_service.id))
return render_template('views/service-settings/branding/email-branding-organisation.html')
@main.route("/services/<uuid:service_id>/service-settings/email-branding/something-else", methods=['GET', 'POST'])
@user_has_permissions('manage_service')
def email_branding_something_else(service_id):
form = SomethingElseBrandingForm()
if form.validate_on_submit():
create_email_branding_zendesk_ticket('something_else', detail=form.something_else.data)
flash('Thanks for your branding request. We’ll get back to you within one working day.', 'default')
return redirect(url_for('.service_settings', service_id=current_service.id))
Link directly to email branding "something else" Previously we duplicated the "something else" email branding form on its own page and embedded in the choices form (if it was the only option). See [^1] for how this looks - it's inconsistent. This DRYs-up the "something else" form by bypassing the choices form when "something else" is the only option. I've also tweaked the "Back" button to be consistent with this behaviour. Making this change also simplifies the choices form, which we'll be adding pool options to shortly. I'd like to make the letters form consistent, but let's see how emails pan out first. Note that the choices form will now show a single radio button if "something else" is the only option. I think that's OK as nothing will link to the page, and the form still works. [^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
2022-03-02 15:36:28 +00:00
return render_template(
'views/service-settings/branding/email-branding-something-else.html',
form=form,
Remove remaining uses of ChooseBrandingForm This was missed in a previous commit.
2022-03-22 16:38:51 +00:00
branding_options=ChooseEmailBrandingForm(current_service)
Link directly to email branding "something else" Previously we duplicated the "something else" email branding form on its own page and embedded in the choices form (if it was the only option). See [^1] for how this looks - it's inconsistent. This DRYs-up the "something else" form by bypassing the choices form when "something else" is the only option. I've also tweaked the "Back" button to be consistent with this behaviour. Making this change also simplifies the choices form, which we'll be adding pool options to shortly. I'd like to make the letters form consistent, but let's see how emails pan out first. Note that the choices form will now show a single radio button if "something else" is the only option. I think that's OK as nothing will link to the page, and the form still works. [^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
2022-03-02 15:36:28 +00:00
)
Split up email branding form into separate pages We were showing the form to request email branding with a button which submits your choice immediately. Now, we only submit the form immediately if "Something else" is the only branding option available to you. If you select any other radio button (or select "Something else" when it's not the only option) we take you to another page which either contains more information or a textbox to fill in the details for the branding you want. There is currently some duplication between the new pages and their tests, but these will be changed in future versions of the work so will start to differ more.
2022-01-28 09:45:59 +00:00
Change both existing branding URLs This changes the URLs for someone to request new email or letter branding to match the new URLs we've agreed for the new email branding changes. The old URLs are still in place for now too to keep backwards compatibility.
2022-02-02 16:44:32 +00:00
@main.route("/services/<uuid:service_id>/service-settings/letter-branding", methods=['GET', 'POST'])
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
@user_has_permissions('manage_service')
def letter_branding_request(service_id):
Use separate classes for branding option forms These are about to become a lot less similar to each other when we add email branding pools. Note that the optional *args and *kwargs weren't used anywhere.
2022-03-03 12:05:44 +00:00
form = ChooseLetterBrandingForm(current_service)
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')
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
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():
Use Jinja template for branding request tickets Following the pattern established by https://github.com/alphagov/notifications-admin/pull/4041/files this commit move the ticket message from a Python f-string to a proper templating language.
2021-10-26 18:06:26 +01:00
ticket_message = render_template(
'support-tickets/branding-request.txt',
current_branding=branding_name,
branding_requested=dict(form.options.choices)[form.options.data],
detail=form.something_else.data,
)
Use Zendesk form for branding requests This changes the Zendesk tickets created when an email or letter branding request is submitted to use the new Zendesk Form that was introduced in https://github.com/alphagov/notifications-utils/pull/899
2021-09-24 09:24:13 +01:00
ticket = NotifySupportTicket(
Split up the branding_request endpoint The endpoint used to handle both email and letter branding, but this replaces `.branding_request` with `.email_branding_request` and `.letter_branding_request` instead. This is in preparation for changing how email branding works. The `from_template` arg was only possible for letter branding, so I've removed that from the `.email_branding_request` endpoint.
2022-01-19 15:39:05 +00:00
subject=f'Letter branding request - {current_service.name}',
Use Jinja template for branding request tickets Following the pattern established by https://github.com/alphagov/notifications-admin/pull/4041/files this commit move the ticket message from a Python f-string to a proper templating language.
2021-10-26 18:06:26 +01:00
message=ticket_message,
Use Zendesk form for branding requests This changes the Zendesk tickets created when an email or letter branding request is submitted to use the new Zendesk Form that was introduced in https://github.com/alphagov/notifications-utils/pull/899
2021-09-24 09:24:13 +01:00
ticket_type=NotifySupportTicket.TYPE_QUESTION,
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_name=current_user.name,
Use Zendesk form for branding requests This changes the Zendesk tickets created when an email or letter branding request is submitted to use the new Zendesk Form that was introduced in https://github.com/alphagov/notifications-utils/pull/899
2021-09-24 09:24:13 +01:00
user_email=current_user.email_address,
org_id=current_service.organisation_id,
org_type=current_service.organisation_type,
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
)
Use Zendesk form for branding requests This changes the Zendesk tickets created when an email or letter branding request is submitted to use the new Zendesk Form that was introduced in https://github.com/alphagov/notifications-utils/pull/899
2021-09-24 09:24:13 +01:00
zendesk_client.send_ticket_to_zendesk(ticket)
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(
Split branding-options.html into two This splits the template into separate templates for emails and letters since the journey for email branding is about to change.
2022-01-19 16:26:57 +00:00
'views/service-settings/branding/letter-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,
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):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceAddDataRetentionForm()
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.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)
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminServiceEditDataRetentionForm(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' link links to edit_service_notes
2021-01-14 18:00:44 +00:00
@main.route("/services/<uuid:service_id>/notes", methods=['GET', 'POST'])
Fix permissions for edit service note page
2021-01-25 14:50:49 +00:00
@user_is_platform_admin
'Change' link links to edit_service_notes
2021-01-14 18:00:44 +00:00
def edit_service_notes(service_id):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminNotesForm(notes=current_service.notes)
'Change' link links to edit_service_notes
2021-01-14 18:00:44 +00:00
if form.validate_on_submit():
if form.notes.data == current_service.notes:
return redirect(url_for('.service_settings', service_id=service_id))
Add test for textarea Also remove redundant error handling - if unexpected error happens, it will be handled at the app level.
2021-01-19 18:13:03 +00:00
current_service.update(
notes=form.notes.data
)
return redirect(url_for('.service_settings', service_id=service_id))
'Change' link links to edit_service_notes
2021-01-14 18:00:44 +00:00
return render_template(
'views/service-settings/edit-service-notes.html',
form=form,
)
Change link leads to edit billing details view
2021-01-25 14:52:07 +00:00
@main.route("/services/<uuid:service_id>/edit-billing-details", methods=['GET', 'POST'])
@user_is_platform_admin
def edit_service_billing_details(service_id):
Rename other "Admin" forms consistently I've also tweaked some of the names to make them clearer e.g. that the form is used to apply a change to a service. I've constrained the scope of this change to avoid forms that may be accessible by non-admins in the future.
2022-03-15 10:50:18 +00:00
form = AdminBillingDetailsForm(
Update attribute names following changes in API
2021-01-26 10:41:22 +00:00
billing_contact_email_addresses=current_service.billing_contact_email_addresses,
billing_contact_names=current_service.billing_contact_names,
Change service billing details View page that lets you change service billing details and update details on form submission.
2021-01-25 15:40:49 +00:00
billing_reference=current_service.billing_reference,
Add notes to edit billing details page As per ticket and as per Caley's request, so everything can be edited together. Also pluralise labels for billing contact info, to indicate that putting multiple in is ok, and widen the input fields so that it is more comfortable to input multiple contact details.
2021-01-27 18:20:25 +00:00
purchase_order_number=current_service.purchase_order_number,
notes=current_service.notes,
Change service billing details View page that lets you change service billing details and update details on form submission.
2021-01-25 15:40:49 +00:00
)
if form.validate_on_submit():
current_service.update(
Update attribute names following changes in API
2021-01-26 10:41:22 +00:00
billing_contact_email_addresses=form.billing_contact_email_addresses.data,
billing_contact_names=form.billing_contact_names.data,
Change service billing details View page that lets you change service billing details and update details on form submission.
2021-01-25 15:40:49 +00:00
billing_reference=form.billing_reference.data,
Add notes to edit billing details page As per ticket and as per Caley's request, so everything can be edited together. Also pluralise labels for billing contact info, to indicate that putting multiple in is ok, and widen the input fields so that it is more comfortable to input multiple contact details.
2021-01-27 18:20:25 +00:00
purchase_order_number=form.purchase_order_number.data,
notes=form.notes.data,
Change service billing details View page that lets you change service billing details and update details on form submission.
2021-01-25 15:40:49 +00:00
)
return redirect(url_for('.service_settings', service_id=service_id))
return render_template(
'views/service-settings/edit-service-billing-details.html',
form=form,
)
Change link leads to edit billing details view
2021-01-25 14:52:07 +00: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