The breaking change page wasn’t properly accounting for the fact that
letter recipients span multiple columns – it was assuming they’d only
take up one column like they do for email and SMS.
This commit fixes:
- the number of column headers (A, B, C, …) to be correct
- the count of columns (you will need X columns in your file) to be
correct
It then parameterises the test to look at a case where a recipient is
in one column (email) and multiple columns (letter).
Our deploys have stopped working. It’s complaining with an `ImportError`
somewhere in Boto:
```
017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR Traceback (most recent call last):
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR File “/home/vcap/app/.heroku/python/bin/aws”, line 19, in <module>
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR import awscli.clidriver
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR File “/app/.heroku/python/lib/python3.5/site-packages/awscli/clidriver.py”, line 33, in <module>
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR from awscli.help import ProviderHelpCommand
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR File “/app/.heroku/python/lib/python3.5/site-packages/awscli/help.py”, line 27, in <module>
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR from awscli.clidocs import ProviderDocumentEventHandler
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR File “/app/.heroku/python/lib/python3.5/site-packages/awscli/clidocs.py”, line 18, in <module>
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR from botocore.utils import is_json_value_header
2017-04-04T10:46:26.17+0100 [APP/PROC/WEB/0]ERR ImportError: cannot import name ‘is_json_value_header’
2017-04-04T10:46:26.20+0100 [APP/PROC/WEB/0]OUT Terminating application process with pid
```
Our version of Boto is a year old. Upgrading it to the latest version
seems like a good idea.
Not a breaking version number change. Changelog here:
https://github.com/boto/boto3/blob/develop/CHANGELOG.rst
Complete changes:
https://github.com/boto/boto3/compare/1.3.0...1.4.4
Brings in:
- [ ] https://github.com/alphagov/notifications-utils/pull/128
This means that `RecipientCSV` will sometimes return the value of a cell
in a spreadsheet as a `list`, not a `string`. So we need to handle that,
rather than putting a Python representation (`['one', 'two', 'three']`)
on the page.
This commit handles it by putting a bulleted list on the page instead.
This breaks our model of showing the spreadsheet as it appears in Excel
or whatever, because we’re showing the aggregation of the columns into a
list. However:
- this is the easier thing to do for now
- it might actually be more usable because it keeps the table narrower
No need to repeat the same field-calling code each time.
Think we didn’t do this before because there was no way of passing the
`status` through to the `text_field` macro.
We set a URL for the app to use to access itself. On PaaS this is
configurable, locally we default to `localhost`. `localhost` doesn’t
(easily?) support HTTPS, so this default wasn’t working.
Users who go to edit the contact details for a letter from the template
page get very confused when they click save and are dumped on the
settings page. It doesn’t match the way editing other parts of
letter works, and you can’t see an accurate preview of the changes from
the settings page.
So this commit changes the flow to go from the _edit contact details_
page back to the _view template_ page when the user has got there by
clicking the blue _Edit_ button on the _view template_ page.
This page is not the place where you edit the contact details. Nor is
it the place where you can preview changes to the contact block. In
research users never found the link to get from this page to the edit
contact details page. So this commit removes it.
pass in the base URL - if not set in the environment this is set to
localhost, but on paas we can pull this out of vcap_services so that
letters render properly on paas
When you’ve sent message(s) using a template, often the next thing you
want to do is go and send the same template again, or edit it.
Currently there’s no way of getting to a template from a job except for
going back to the list of templates and re-finding it.
This commit adds a link at the bottom of the job page that gives you a
shortcut back to the individual template, where you can find actions
like edit/send/etc.
Tests assumed that the API returns the template `id` as part of the
object. It doesn’t – it returns it as the key used to look up the
object. The `id` was missing from the transformation into the format
used by the front end.
For some reason Flask is fine building the URL with `template_id=None`,
but obviously this doesn’t generate a valid link.
Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
Making the navigation narrower means that we have more space on every
page. So on pages where we had to use 16px type just to fit stuff on the
page we can now bump the type size up to something less miserly. This is
mainly the team and settings pages.
We still need to use 16px on pages which list notifications or previews
of spreadsheets, because we’re still trying to fit a lot of information
onto these pages, so every little space-saving helps.
When adding a letter it’s hard to know how the stuff you’re typing is
going to look. So rather than go straight to the edit form let’s show
users a blank letter. They can then choose which part of it they want
to edit first. And will have a better idea of how their changes are
going to show up.
In research we also saw nervousness around saving a template and wanting
to ‘preview’ it first. Hopefully this flow will make people feel less
precious about saving a template because they’ve already done it once
just by creating the template.
When you add a new template the next thing you want to do is probably:
- send a test
- edit it after seeing what it looks like
So let’s redirect you straight to the page where you can do these
things.
This is especially important for letters where we want to tighten the
edit/feedback loop.
Like the template ID this is an infrequently-used action on a template
and doesn’t belong at the same level as ‘Upload recipients’ or
‘Send yourself’ a test. We don’t think it’s information that’s useful to
working out which template you want to interact with, so it shouldn’t be
on the choose template page any more.
