Spreadsheets start at row 1 (the header row), and the values don’t start
until row 2. The row numbers in our URLs start at 0, which is a concept
that only makes sense to programmers.
It’s more predictable and consistent to make the number in the URL match
the row number displayed on the page when previewing the spreadsheet.
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.
This commit adds links to all but the currently-previewed row. Clicking
that link will populate the preview with values from that row. These
pages already exist; they were created in this PR:
https://github.com/alphagov/notifications-admin/pull/1696
VCAP_SERVICES is not set on PaaS if no services are bound to the
application, so we need to check for VCAP_APPLICATION to parse the
application name and environment.
We're no longer using user-provided services for application secrets
so we can remove the cloudfoundry_config code responsible for parsing
VCAP_SERVICES.
flake8-print is a flake8 plugin that checks for `print()` statements in
Python files.
This should save us having to manually spot these when reviewing pull
requests.
The `--enable=T` flag needs to be set until this bug is fixed:
https://github.com/JBKahn/flake8-print/issues/27
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.
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.
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.
Easier to test the individual aspects of what’s going on here if they’re
two separate tests, one hitting the initial `POST`, and one hitting the
page that they’re subsequently redirected to.
The `client_request` fixture means the tests take fewer lines of code
and also checks some extra things (eg page titles matching <h1>s).
Changing it in this commit, independently of functional changes to this
test.
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.
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.
