We’ve had a support ticket saying:
> Hi, where a letter goes over to two sides, is there a way in the
> 'Preview' screen (or anywhere else) that I can see page two? I can
> see page one OK, but can't work out how to see what's generated on the
> second page.
Whether you’re about to send 1000s of letters – or just want to preview
how one will look – it’s probably useful to be able to see more than
just the first page.
Pytest is deprecating the direct calling of fixtures. One fixture that
we call directly quite a lot is `fake_uuid`. Since it just returns the
value of `sample_uuid()` we can either call that instead (where we need
a fixed value) or generate a new UUID each time (where a fixed value is
not needed).
Users come to this page from various places, including the new 'Sign
the…' link on the request to go live page.
Of these users:
- some won't have signed it
- some will have signed it
- some will see that it's complete and wonder why, as they haven’t
actually done anything
So it’s more appropriate for the title of this page to be descriptive,
rather than an action.
2/3 of our incomplete requests to go live are incomplete because the
Data Sharing and Financial Agreement isn’t signed.
We reckon we can be pushier about this by saying it’s ‘incomplete’ where
we know the agreement is signed.
Where the agreement is signed we should confirm this, rather than make
the line disappear. This is so it makes more sense to someone who sees
it as ‘incomplete’, signs it, then comes back to the page.
If we don’t know whether or not the agreement is signed we should wait
until someone has got in touch with us by requesting to go live to
figure it out. So that’s why we’re not showing that line at all.
This duplicates how the task list pattern is coded in the GOV.UK
Prototype kit[1]. It adds ARIA attributes and the use of a
semantically-meaningful element (`<strong>`) to give more information to
screen reader users.
1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
This tag was not showing up in the call to the Zendesk API because the
return value of a generator is not included as a member of that
generator (on things `yield`ed from it are).
At the moment we manually tag tickets as they come in so we can analyse
how many of each type we’re getting.
Further, we manually tag all the request to go live tickets once a month
to analyse how many are complete/incomplete.
All this tagging is useful, but quite time consuming. Notify already
knows this information and – using the Zendesk API – we can tag them
automatically.
I’ve checked with Holly and this is the taxonomy we want to use.
