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).
Currently we have a bunch of users who aren’t signed in asking us for
the agreement.
This is bad because:
- it’s slower (for them) than just being able to download it
- it creates work for us
We can’t just offer the agreement to anyone, but we can offer to it to
anyone who’s signed in because we now let people self-select which
version to download when we can’t tell which one to give them.
p1 == "should notify team be alerted of this (via pagerduty)"
urgent == "should the user be told we'll look at it"
* If it's in office hours, it's always urgent. It's never a P1 because
we'll notice it anyway
* If it's outside of office hours, it's urgent and P1 if it's severe,
otherwise it's neither
I don’t think it’s a massive risk (we’re certainly mitigating against
any XSS), but having a page on a GOV.UK domain where you can prefill
text on the page from a query string probably isn’t great.
So this commit restricts prefilling the support form to a set of
named questions.
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
The idea is if you decide your problem isn’t such an emergency after
all, we direct you to the form where you can report it as such. This
link wasn’t working because it didn’t understand `False` to mean ‘not
severe’. Only ‘no’ means not severe.
The result was that users got sent in a bit of a convoluted loop
where they were asked again if their problem was an emergency or not.
Testing this by making sure that both:
- the URL in the link is what we expected
- when visited it gives the page title we expect
Because even if we had had the first test only, it wouldn’t have caught
this bug.
Cool URIs don’t change 😎https://www.w3.org/Provider/Style/URI
We still have links to `/feedback` in our emails. These will live in people’s inboxes forever.
The support flow was using `yes` and `no` to mean emergency/not
emergency. But not in all places – in one place it was using
`True`/`False` instead.
We were treating anything other than `yes`/`no` as a non-answer, which
means ask the question again. Because of the `True`/`False` thing, there
was no way of the user providing a valid `yes`/`no` answer. Which means
that we just kept asking them the question again and again and they got
stuck in a loop.
(I suspect that) because Python dictionaries are not ordered, you can’t
rely on the order of query parameters in a URL to match the arguments
passed to `url_for`. This means the tests can intermittently fail.
This does some hacky workaround stuff to still have reasonable test, but
one that will pass whatever the order of the query parameters is.
`severe` can mean one of three things:
- `yes` – user has told us this is an emergency
- `no` – user has told us this isn’t an emergency
- Anything else – user hasn’t been asked the question or has
hacked/mangled the URL
This commit adds some stricter sanitisation of the `severe` query
parameter and does so up front, rather than spreading it across multiple
functions.
`replace` doesn’t convert a time from one timezone to another. It just
changes the label that says what timezone a time is in 😬
`.localize` is how we handle these kind of issues in the API (see
d0b467b2fb/app/utils.py (L42-L44) )
So this commit changes the calculation to use `.localize`, and makes the
tests timezone aware to check we’re doing this right.
Using and/or over any/all has a couple of advantages:
- it's a bit quicker
- it won't evaluate the second half at all if the first half fails – if
it is in business hours, and convert_to_boolean would raise, with your
use of all we'd throw a 500, whereas if we had or, business_hours
would trip and we'd skip over the second half without worrying about
exceptions
any and all are designed for use with variable length args eg
`any(x for x in thing())`
If you report a problem we want to be able to get back to you to find
out more information, or to update you on the status of a fix. So it
shouldn’t be possible to report a problem without providing an email
address.
This commit makes `email_address` a required field when `ticket_type` is
problem.
This requires a bit of fiddling with the tests which weren’t expecting
to have to provide an email address. So the tests now either:
- pass an email address
- check for an error when they don’t pass an email address
This is a real edge case, but it seems worth handling.
How you’d get to this case:
- it’s 5:29pm and you start to describe the problem you’re having
- it’s 5:31pm and you click ‘submit’
- you’re redirected to the triage page because we’re now out of hours
- you click ‘this is a serious problem’
What would be bad thing to happen:
- you’re back on the message page and all the stuff you’ve written is
gone
What would be a good thing to happen:
- we save the message in a session so that you can check it again before
sending it
Generally I prefer confirmation pages to the flash message thing
(they’re harder to miss). So this commit adds one.
It also adds some logic to this page, so that, depending what the user
has told us about the thing they’ve submitted, we can tell them how
quickly to expect a response.
TL;DR, as much as possible we should work out how to prioritise tickets
and not put that burden on the user. However, there are some cases where
we can’t.
In business hours all tickets are high priority, ie we will at least
acknowledge them within 30 mins.
If we are not in business hours then we need to know if a ticket is
serious enough to get someone out of bed. Only the user can tell us
this, but we can give them some examples to help them decide.
In addition, out-of-hours tickets are only a priority if the user has
live services. Normally we can determine this and do the
priority-setting in the background.
If they can’t log in then we can’t determine what services they have. So
in this case they will need to use the emergency email address, which
only users with live services will have.
The logic for this gets fairly complex. It might be to easier to
understand what’s going on by walking through the test cases, which are
a bit more declarative.
N.B. Deskpro’s ‘urgency’ is descending, eg 10 is the most urgent and 1
is the least.
If a user is logged in then we already know their name and email
address. So there’s no need for them to fill them again on the support
form.
One concern we might have about this is the user not realising we’re
doing this, and the feedback form looking like a bit of a black hole.
So we’re replaying their email address on this page to reassure them
that:
- we know who they are
- and that they’ll get a reply
The kind of communications we’re getting at the moment can broadly be
broken down into:
- problems
- questions and feedback
We will need to triage problems differently, because they could
potentially be urgent/severe/emergency/P1/whatever language we use.
Questions or feedback will never be P1.
Two reasons for making the user categorise their tickets themselves:
- Outside of hours we can’t get someone out of bed in order to decide if
a ticket is a problem or just feedback
- We can tailor the subsequent pages to whether it’s a problem or
feedback (eg showing a link to the status page if the user is having
a problem)
This commit let’s users make the choice with a pair of radio buttons.
It also cleans up a bunch of the tests and parameterizes them so we’re
testing the flow for both ticket types.
Our support process is about to get more fully fledged so we’ll need
an index page to route people properly.
We reckon that users will also want to know what the support process is,
so let’s explain it on this page.
