When we’re doing user research we often:
- start the task by inviting the participant to a service on Notify
- have them use a prototype version of the admin app, hosted on a
different domain
Currently we can’t do both of these things together, because the invite
emails always send people to notifications.service.gov.uk (because it’s
the API that sends the emails, and the prototype admin app points at the
production API).
This commit changes the admin app to tell the API which host to use when
creating the invite links.
Depends on:
- [ ] https://github.com/alphagov/notifications-api/pull/1515
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
We wouldn’t wan’t anyone just seeing the raw CSV data in their browser – it isn’t clear what a user would do with it at that point. And we wouldn’t want it navigating them away from the send page, because this might cause them to lose their place.
This commit forces the file to download using the HTML5 `download` attribute:
> This attribute instructs browsers to download a URL instead of navigating to it, so the user will be prompted to save it as a local file.
– https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download
Email addresses in invites should be case insensitive. This is to stop
the bug where a user creates their account using a lower case email
address (e.g. user1@gov.uk), but is then invited to a service using
their email address in a different case (e.g. USER1.gov.uk) and sees
an error message telling them that they can't accept an invite for a
different email address.
DVLA DM Contact Centre Driver & Vehicle Licensing Agency
DVLA Contact Centre Complaints Driver & Vehicle Licensing Agency
School Admissions Buckinghamshire County Council Buckinghamshire County Council
Submit a GAR Home Office
G-Cloud Commercial Agreement Team Crown Commercial Service
Tracio Fflyd Gwynedd Council
We weren’t calculating the height quite right; we were trying to
compensate for something that should have been compensated for in the
`stick-at-top-when-scrolling` code.
Add the 5px to the shim there is required because we’re adding it to the
element that the shim in replacing.
There were three problems with showing tables fullscreen:
- it was over-optimised for very big spreadsheets, whereas most users
will only have a few columns in their files
- it was jarring to go from full screen and back to the normal layout
- it was a bit change for existing users, where we prefer incremental
changes that make things better without disrupting people’s work
(where possible)
So this commit changes the big table to scroll horizontally in the page,
not take up the full width of the page.
From the fullscreen table it keeps:
- the shimming method to keep the horizontal scrollbar at the bottom of
the screen at all times
It introduces some more refinements to make it nicer to use:
- fixing the first column, so you always know what row you’re on
- adding shadows indicate where there is content that’s scrolled outside
the edges of the container
Two bits of context:
1. As we start dealing with letters, which have more columns, it’s more
likely that people’s spreadsheets won’t fit in our current layout.
2. We already removed the view of the template from the page that shows
row-level errors (eg bad phone number or missing personalisation) in
spreadsheets because you don’t need to know about the content of the
message in order to fix the errors.
This commit goes further by removing anything that isn’t to do with
the errors, including the normal GOV.UK header and the service’s
navigation.
This means the content can go the width of the page, which means it can
be allowed to scroll horizontally without being a usability car
crash. Which means that the layout doesn’t break with a spreadsheet that
has lots of columns.
Because exceptions can be expensive performance wise (see:
https://docs.python.org/3/faq/design.html#how-fast-are-exceptions).
Since we’re counting the number of rows anyway this doesn’t introduce
any performance overhead there. And I think it’s equally readable/same
number of lines of code.
We’ve heard from some users, especially those sending letters, that
they’d like to check that a spreadsheet they’ve uploaded has populated
the template correctly.
My reckon is that seeing just one row of the spreadsheet populate the
template isn’t enough to give people confidence that everything’s
working properly. So this commit is the first step towards being able
to preview an arbitrary row of a template, by extending the URL
structure to optionally accept a row number for pages or files (ie PNG)
that preview successfully uploaded spreadsheets.
What this commit doesn’t do is link to these pages; that will come as
part of a subsequent commit.
Since instances of `Recipients` are now iterable we can just look up the
first row by index, rather than having to hit the rows property as a
generator.
There is a chance that there won’t be a first row, if the file has 1 or
fewer columns. So we still need to handle a possible exception (albeit
it a different one to before).
This variable isn’t used by our Jinja templates. Presumably it was
from the time before instances of `Template` were responsible for
showing who the email/text message was being sent to.
Since we’re doing this globally, we don’t need to handle it in a custom
way for the sign in form (and it’s much nicer encapsulated like this).
Also added some more extensive tests in this commit.
We’ve had whitespace-in-emails problems on:
- register form
- sign in form
- send one off form
We should just handle whitespace gracefully, by ignoring it. Makes sense
to do this at a global level because there might be other places it’s
causing problems that we don’t know about.
The only place that users _might_ be relying on leading/trailing spaces
(and we have no way of knowing this) is in passwords or tokens. So this
filter ignores any instances of `PasswordField`.
Adapted from @pcraig3’s work on Digital Marketplace:
- 4b06f5cfb7
- e761c1ce65
Delivery comes before inbound. The order of the URLs was jumbled in two
places:
- in the view function
- in the Jinja template
So as the user saw it the URLs were in the right order, because the
double jumbling cancelled itself out. But it made the code _really_
confusing to read.
When viewing a letter template, there is a button to edit the letter
contact block. This should take the user to the page to edit the letter
contact block, but if a service has not set any letter contact blocks, the
button was returning a 404 error.
The code has now been changed so that if the service has no letter contact
blocks the edit button will link to the page to add a letter contact
block.
Pivotal story: https://www.pivotaltracker.com/story/show/152881444
We call the yellow things ‘double brackets’ on the frontend, not fields
or placeholders. This error message was a bit out of date.
Also refactored it to use the `Field` class; this code was probably
written before `Field` was factored out of `Template`.
If you copy and paste an email address into the sign in box, there’s a
chance you’ll also copy some leading or trailing spaces. This is
especially likely to happen if you’re doing this while using your
computer upside down.
If this happens, it never even gets as far as looking up the user,
because the form validation doesn’t consider a string with a leading
space to be a valid email address.
This commit makes sure that accidental spaces are handled, by removing
them before doing any validation or hitting the API to look up the user.
