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
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).
a form that allows you to clear entries from the cache for all of
either users, services or templates. It'll tell you the largest amount
of keys deleted, since there are multiple keys associated with each
model.
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.
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.
This has a form with 3 fields - the file upload field, logo name, and an
optional logo domain. Logos need to be uploaded in `.svg` format and we
then convert this to `.png` format and upload both file types to S3 as
well as saving the letter branding details in the database.
This introduces a validator to validate that the name field is not empty
on the ServiceUpdateEmailBranding form, but only if the form details are
being submitted. If a file is being uploaded, the name is allowed to be
empty.
If Optional runs before required_for_ops, it stops
the validation chain so it doesn't get to
required_for_ops. The move_to field isn't required
for the 'move-to-new-folder' operation, so this has
been removed.
This also adds comments explaining why we set
default to an empty string when instantiating the
move_to field.
Updated the move folder form to add a hint for the radio button for the
current folder saying 'current folder'. This hint does not get shown if
you are viewing all folders (so you are not inside a folder).
Also stopped a default radio button from being selected on the form.
Otherwise we can end up collecting invalid email addresses…
This required some refactoring to allow our email fields to be optional
(but not by default).
so that they better align with the front-end, where they'll be used in
data attributes. Also, making the kebab case is nice because it doesn't
give favouritism to either JS or python naming conventions
WTForms coerces `None` as a choice to `'None'` as a string when
rendering form fields (form fields will only ever have string data
because that what the browser posts back).
But internally WTForms coerces `None` to mean an unset value, ie where
the user hasn’t selected a radio button:
283b280320/src/wtforms/utils.py (L1-L20)
We shouldn’t use `None` to mean two different things. And in fact we
can’t, because it in effect means that we’re always getting a value
for the `move_to` field, even if the user hasn’t chosen to move any
templates. Which results in some very expected behaviour.
Since we’re letting users add new folders directly from the choose page
it makes sense that they should also be able to add templates from
there.
This resolves the problem we saw in user research where people found it
hard to know where to go to add a new folder when they were all behind
one green button.
this lets us combine the two actions to create "Move to a new folder".
If the user hits enter rather than clicking a button, there is a hidden
submit button that (for now) prevents them from taking any action.
A future commit will try and understand what the user might be doing
based on which fields are populated/selected.
Since you can now see them when searching you should also be able to
select and move them. Which means that they needed to be included in
the `Form`’s list of possible choices of things to move.
Follows what we’re doing with the folders stuff. Avoids having too many
very straightforward methods on the model. Especially when the data they
need is only used by the form. So it’s better to encapsulate the logic
in the form.
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
This commit adds logic to:
- take the list of selected folders and templates
- split it into two lists (of folders and templates)
- `POST` that data to the API, to effect the movement of said folders
and templates
I’ve tried to architect it in such a way that we can easily add more
template ‘operations’ in the future, as we add more forms to the choose
template page.
