The difference between created and sending isn’t something a user should
have to care about. So this commit:
- counts created and sending as the same thing
- displays and notifications which have a status of created as sending
Currently images in our email template are hardcoded to be served from
the live domain[1].
In order for the admin app, running locally or in preview/staging, to be
able to load these images when previewing an email template, the CSP
headers need to allow this domain.
Also splits the header string up using string literal concatenation[2]
so that it’s easier to read.
1. https://notifications.service.gov.uk
2. https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation
If something has failed and you don’t know why, you should be able to
find out why. Let’s try adding a link to the page explaining why, so
it’s not just buried in the footer.
‘Phone number doesn’t exist’ as opposed to ‘Permanent failure’ has
tested well because it talks in terms of things people understand.
We should do the same for ‘Temporary failure’, because users are
unclear:
- why this is happening
- if it’s temporary, is Notify going to retry it (it’s not)
We think that ‘Phone/inbox not currently accepting messages’ answers
makes these things clearer.
I’ve reworded it slightly to:
- ‘Inbox not accepting messages right now’
- ‘Phone not accepting messages right now’
This commit refactors the `email_message` and `sms_message` UI components to
take fewer parameters.
`name`, `edit_link` and anything to do with versions are identical for both
text and email messages so I’ve moved them to the pages where you choose a
template or see the versions.
This commit also tidies up the wording and styling of the template history
stuff.
With the upgrade of pep8 to 1.7.0 module imports are required to be at the top of the file,
meaning I had to add a noqa line to some of the init files. Are those init files wrong or is pep8 too strict.
Use the new version of the notifications-python-client. This version no longer adds the req and pay to the claims of the jwt.
The change is backward compatible so an older client that sends a JWT with the extra claims will pass authentication.
Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well.
The documentation has been updated to reflect this change.
https://www.pivotaltracker.com/story/show/116971293
There is a bug in Babel[1] which means that it throws an exception if
it can’t find the locale it wants to use.
This is not a problem when developing locally, because OS X comes with
lots of locales. The AWS machines, however, only have one locale, which
is not the one that Babel is looking for. Hence the ‘Activity’ page
doesn’t work.
This commit changes to using Humanize[2] instead, which is much less
vast and hopefully less hungry in its requirements.
That’s a morning we won’t get back…
1. https://github.com/python-babel/babel/issues/137
2. https://pypi.python.org/pypi/humanize
This table had a lot of columns, which meant that some of them became
very narrow, wrapping the text awkwardly.
This commit groups some of the data into a chunk, which occupies the
first column.
- no config overrides - now all set in environment
- use different files for staging and live too allow for differently named env variables
- updates to run_app and run_tests scripts to set correct environment (test/development) so correct config picked up
- use environment file on deployed environments to pick correct config
