when you hit the delete button, it flashes the delete button and takes
you to the `/service/../user/../delete` url. If you then click the save
button, it would make a POST to the delete URL... and delete the user.
now the page stays on the edit url, but adds a `?delete=yes` query
string. The dangerous flash banner now has an action field which
defines where the browser will make the POST to (which remains at
/delete).
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.
If a new user is being invited for a service which doesn't have edit
folder permissions turned on, we want to send all folders for that
service to api.
The api endpoint to get all template folders also returns the users who
can see each folder.
We need to clear the template-folder cache when adding a user to a service so
that we are not using out of date data about who can see each folder.
Added a folder permissions form to the page to invite users to services.
This only shows if the service has 'edit_folder_permissions' enabled,
and all folder checkboxes are checked by default. This change means that
InviteApiClient.create_invite now sends folder_permissions through to
notifications_api (so invites get created with folder permissions).
Started passing the folder_permissions through to notifications-api when
accepting an invite. This changes UserApiClient.add_user_to_service to
send folder_permissions to notifications_api so that new users get folder
permissions when they are added to the service.
We were already invitializing InvitedUser with folder_permissions
(defaulting to None), but this removes the default and adds
folder_permissions to the serialize method. Folder permissions should
now always be returned from api, either as an empty list or a list of
UUIDs.
When we get a request for new branding it’s helpful to quickly see what
the service’s current branding is, so we can get a better sense of why
they want to change it.
The endpoint for adding a user to a service in api will now deal with
both user permissions and a user's folder permissions, so this changes
the format of the data we pass through.
Putting the permission check in the get_user_template_folders allows
us to replace `all_template_folders` usage with the new method without
having to worry about the temporary service permission flag.
It should be:
- if they have said they are going to send by a certain channel, show
the extra required task(s) for that channel
- if they haven’t said, infer from which templates they have
Integrates the folder permissions form with the updated API endpoint
to store changes in the user folders.
Since user folder permissions are returned in the full list of template
folders for the service we need to invalidate the cache key for it each
time we update user permissions.
We're reusing the logic for the `move_to` nested radios field for the
user folder permissions nested checkboxes.
The main difference between the two forms (aside from the different
input type) is that "Move" form contains the root "Templates" as an
option, whereas the folder permissions doesn't.
It turns out that, because of the way NestedFieldMixin.children and
select_nested macro are implemented the easiest way to get the desired
folder permissions behaviour is to add the root folder as a choice with
a `None` value and `NONE_OPTION_VALUE = None` set on the field, which
allows the `child_map` to be constructed but doesn't display the root
folder checkbox itself since it gets overwritten in the final `child_map`.
If you have email templates but haven’t told us what volumes you’re
sending we should assume you are going to send emails. We should only
stop asking you to add a reply-to address once you’ve told us for sure
you’re not going to send any emails.
This also applies to changing the text message sender – this should only
be hidden if you don’t have text message templates or you’ve said you’re
not going to be sending any text messages.
We have a number of go live requests where people have said they’re
sending text messages, but haven’t changed the text message sender from
the default of `GOVUK` (we ask teams who aren’t central government to do
this). At the moment we don’t prompt them to, because we look at whether
they have text message templates as indicative of whether they’re going
to send text messages.
Now that we explicitly ask for the volumes of text messages they’re
sending we should use this to determine whether or not we prompt them to
change their text message sender because it’s a stronger signal of
intent than what templates they’ve set up.
We have a number of go live requests where people have said they’re
sending email, but haven’t set up a reply-to address. At the moment we
don’t prompt them to, because we look at whether they have email
templates as indicative of whether they’re going to send email.
Now that we explicitly ask for the volumes of email they’re sending we
should use this to determine whether or not we prompt them to set up an
email reply to address because it’s a stronger signal of intent than
what templates they’ve set up.
At the moment it 500s because it can’t format the `None` values as
numbers.
In the future we will stop people requesting to go live until they’ve
provided this info. For now it has to be optional.
Things we talked about:
• asking users to write the number 'as numerals' or 'using digits' isn't
very plain English
• the style guide says to use an example in the error `..., like 5,000`
but not if you have an example in the hint text, so we can't do that
• I have reservations about 'correct format', because it sounds odd if
you're not describing something like a phone number, NI number or
credit card number.
Looking back through Request to Go Live tickets on Zendesk.
---
I got to September before I found anything that would count as invalid
under our new rules:
> Possibly around 1,000,000- not planning on implementing emails yet but
might change
I'll keep looking, but if most people enter the number according to the
hint example we might be able to go with a much simpler error just
prompting them to enter a number – no convoluted descriptions of what we
mean by a number
There seemed to be more problems when the Qs were about start volume and
peak volume. Users felt the need to explain their plans more.
Using 'number' instead of 'volume' is more explicit too – so that
probably helps.
In terms of errors:
`Enter the number of emails you expect to send`
`Enter the number of text messages you expect to send`
`Enter the number of letters you expect to send`
– will probably do it, right?
It’s annoying and very ‘computer says no’ to make people type `0` in a
box. We can see from our analytics that this error is affecting about 7%
of users trying to go live.
This commit relaxes the validation to only require a number greater than
1 for at least one of the questions.
It also lets people enter their numbers comma-separated – like our
examples suggest – but normalises them to integers before sending them
over to the API.
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
