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.
Skewing the letter results in a bunch of slightly-off-vertical diagonal
lines. This is a bit visually jarring when everything else on the page
lines up vertically or horizontally.
This commit makes the bottom half of the letter straight, by offsetting
it instead of transforming it. The ‘fold’ now has depth, so it has to
be drawn in somehow, that’s what the `:before` is doing.
This might be taking the skeumorphism too far (especially with the
animation). But it’s a way of indicating that the letter will ‘unfold’
if you click it. Might revert this, but let’s see how it feels.
Users might wonder why they can’t see the whole letter. We should make
it obvious that it’s because the letter is folded. We can use CSS to
draw the bottom half of the page behind the top half. With some
transforms this makes it look like the letter is actually folded.
It’s a bit skeumorphic but:
- I think it achives the desired effect
- the way we show emails and text messages is also mildly skeuomorphic
The letter previews take up too much space on the page (more than a
typical email or text message). This means that users have to scroll too
much.
When we send the real letters they will be folded in half to fit in the
envelope.
So by showing the letter previews on the page cropped to half the
letter’s height:
- it reduces the need for scrolling
- it gives an accurate preview of how the letter will be delivered
This is acheived without hard-coding any heights by using a little-known
quirk of CSS, namely that padding set as a percentage is calculated from
the width of the element, even for top/bottom padding. This means that
we can always set the ratio of the displayed letter to be A4 folded in
half – the square root of 2.
The PNGs we were generating looked a bit fuzzy, and the text rendering
was a bit off.
This is because we weren’t rendering them at a high enough resolution.
I’m guessing the default was 72dpi. This commit increases the resolution
to 96dpi, which (locally) seems to be enough to give a good-looking
preview.
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
Non-outlined text requires the correct font to be installed to display
properly.
Outlined text is the shapes of the letters converted to vector, so it
doesn’t need any font installed to display.
Since we don’t have the right fonts installed on the boxes yet, this
will make things look better.
One of the user needs that we identified is not wanting to be the first
to use it. It feels like a much less risky choice if there are already
other people in government using it.
The easiest way to communicate this is with counts of how many services.
The count of departments is good because it shows breadth, where the
count of services shows depth.
Hard coded for now because we have no automatic way of splitting our
test services from real live services.
‘How much does it cost’ is one of the user needs that we identifed for
the product page.
Cost is not the primary reason someone would use Notify (they’re more
likely to cite ease, or that it’s ‘official’). However if you _don’t_
mention cost then it looks like we’re hiding something or that there’s
a catch. So putting it on the page allays fears that people might have,
rather than pushing them towards using it.
Visually I’ve dropped the size of the `<h2>`s on this page so that
there’s enough difference between them and the big numbers. The idea of
the big numbers being big is to catch people’s attention as they scroll
down the page, by breaking up the rythmn.
The button was inheriting a green box shadow from the default GOV.UK
button style, which is typically used on a white background. On the blue
background, a darker blue shadow looks better I think.
The 15% darkening is the same as used by the default green button:
a3fe44e00e/stylesheets/design-patterns/_buttons.scss (L36)
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.
Many departments are reporting being logged out during usage of the app
This may be because they present differing IP addresses to Notify on different requests due to outbound proxies and so on
Swicthing session protection to None means and IP change won't log a user out.
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/