The url was not being properly formed, missing the tempalte_id, meaning the back button on the page did not work.
This fixes that, includes a check of the url for the back button.
Problem: it wasn’t saying ‘phone number’ or ‘email address’
Why: we renamed `Recipients.recipient_column_header` to
`Recipients.recipient_column_headers`, and made it return a list, not
a string.
The fix: take the first item of the list, and use that to decide whether
it’s phone numbers or email addresses that you’re not allowed to send
to.
N.B. This won’t work for letters, but we don’t know how trial mode is
going to work for letters anyway.
(previously it would have sent them to the choose template page)
if the user has added new templates or deleted the example one,
they're clearly competent enough to use the app so don't worry
(we wouldn't know what URL the tour starts on since the UUID of
the example template is random)
We don’t want sanitized content going into the database, because
sometimes we need the content unsanitised. The path from admin to the
API is where the template goes on it’s way to the database. So let’s
make sure we’re not sanitizing it at this stage.
We can no longer trust that the content of templates stored in the
database is safe.
Utils now has code to sanitise the content of templates.
This commit:
- updates utils to bring this code in
- modifies some integration tests to make sure everything is working
(there are more extensive unit tests in utils)
previously we were issuing a flask redirect (302) from the function,
which we then attempted to unpack as a dict further down the line.
raise a werkzeug.routing.RequestRedirect (301 MOVED PERMANENTLY)
instead. note: only use this pattern when the URL they attempted to
access will *NEVER* be valid, as 301s are cached by browsers.
There is a check that the template can not be created as priority if the user is not a platform admin.
There is a check that the template can not change the `priority` unless they are a platform admin.
Right now we can show what a letter template looks like as a PDF or PNG.
This commit completes the work so this is also possible when:
- showing a template with the placeholders replaced
- showing any version of a template
Also removes dependency on `Exception().message`, which was deprecated
in Python 2.6. See
97f82d565f
for full details.
The flow is as follows:
If the invited user clicks on the /invitation/<token> link in the email (now on /register-from-invite),
then goes to another browser and registers for Notify.
Coming back to the other browser, submit the form for /register-from-invite.
This PR fixes that bug and adds a couple tests for register_from_invite
The breaking change page was taking the rendered template and saving
that if the user confirmed the change. This meant that templates could
be saved with `<span class="placeholder">…</span>` in their subject line
for example.
This commit fixes it so that it uses whatever data the user submitted,
not the rendered version of this.
The PDF preview is all good, but it’s hard, finickeity and feels dirty
to embed a PDF in a web page. It’s a more natural thing to embed an
image in a web page.
So this commit adds another endpoint to return an image of a letter
template. It generates this image from the PDF preview, so the stack
looks like:
1. `template.png` (generated in admin)
2. `template.pdf` (generated in admin)
3. HTML preview (generated by a `Renderer` in utils)
4. `Template` instance
5. serialised template from API
6. Template stored in database
The library used to convert the PDF to an image is Wand[1], which binds
to ImageMagick underneath. So in order to get this working locally on a
Mac you will probably need to do:
`brew install imagemagick ghostscript cairo pango`.
To get it working on Ubuntu/EC2 is an exercise left to the reader…
1. http://docs.wand-py.org/en/0.4.4/
Previewing a letter is different to previewing an email or text message
because:
- a letter has a layout
- the layout is fixed, ie it doesn’t depend on the user’s device
- the ‘send yourself a test’ feature won’t be as useful because it has
a lead time, so the feedback loop will be much longer
For these reasons a HTML-only preview of the letter won’t be enough (we
don’t think). A PDF is more appropriate because:
- it can replicate the layout of the letter exactly
- it is a print format, so the user could even print themselves a copy
locally to get a feel for how it will look
This commit makes use of Flask WeasyPrint [1] to take a HTML
representation of the letter, convert it to a PDF and serve it back to
the user.
The actual work to generate the HTML and specify the layout is done in
utils, same as we do for rendering other messages.
1. https://pythonhosted.org/Flask-WeasyPrint/
