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.
Features is a sales tool. Once you’re using the product already there’s
less of a need to see it. The pages are still accessible from the
footer, and for users who aren’t signed in.
It doesn’t make sense to have a section called ‘Support’ which has a
link called ‘Support’ in it.
And by splitting up, and reducing the number of links in the footer,
they don’t _need_ headers – hopefully they’re self explanatory.
The features nav is supposed to navigate your between pages in the app.
It’s very unexpected to have it open an external link.
Performance isn’t strictly a part of Support, but it’s worked having it
there for long enough that it’s probably not a bother.
