This copies what the other GaaP components will be doing for their
product pages.
The SASS and HTML is taken from here:
f05ca1fb71/source/stylesheets/modules/_breadcrumbs.scss
Only changes I’ve made are:
- making the file paths work with our build pipeline
Changes to our code to accomodate this are:
- putting the padding on the product page `<h1>` not its container
- moving the hero image accordingly so that it lines up
- making the `<main>` element on the product page into an anchor so that
the breadcrumb can link to it – screenreader will then announce the
link as “GOV.UK Notify, same page”
The ticks and crosses on the team page are served bigger than actual
size (128×128px). They are then resized using CSS3 `background-size`
to their displayed size (19px).
The reason for doing this is so they display crisply on retina screens.
IE8 doesn’t support `background-size` (see
http://caniuse.com/#feat=background-img-opts). This means that the ticks
and crosses get show at their original size (way too big).
This commit adds resized versions of the ticks and crosses which are
then served to these older browsers only.
We grey-out the non-current step in the tour so the user knows whether
they’re at step 1, 2, or 3.
This is done using CSS opacity.
IE8 doesn’t support the standard CSS opacity syntax. But it does support
the weird, old, Microsoft-specific `filter:` syntax. So this commit:
- makes the greying out a class rather than an inline style, to reduce
duplication
- adds the filter syntax so the greying out works in IE8
The layout of the totals on the dashboard was getting horizontally
squashed on older versions of IE.
This was something to do with the `grid-row` CSS class no longer being
applied when AJAX updated the page. Grid columns don’t work properly
unless they’re contained in a grid row.
This commit wraps the `div` with `grid-row` in another `div`. Not
totally sure why this works, but it’s something to do with how the
DiffDOM algorithm is working. Seems like the simpler the diff it has to
compute, the better chance it has of not messing things up.
We have a bunch of helper classes (bottom gutter) which are used to
vertically separate components on the page.
This vertical spacing might get ignored if one of these containers
contains floated items. This is because:
> elements that contain floated items don't take those floated items
> into account in calculating their height
– https://css-tricks.com/containers-dont-clear-floats/
GOV.UK Frontend toolkit has a shim to prevent this from happening.
d15e738b92/stylesheets/_shims.scss (L38-L55)
So this commit uses that shim to make the spacing consistent in older
and newer browsers, irrespective of whether floats are being applied.
This hasn’t been a problem because we’re not using a lot of `float` in
Notify. But we are using it now to work around some other
inconsistencies in old browsers.
We use flexbox to lay out the counts of sending/delivered/failed on the
activity and job pages. flexbox makes the best use of the space when
the numbers can be significantly different widths (eg 0 sending, 5000
delivered).
Flexbox was only supported from IE 11 onwards [1]. And since we were
setting the `display` property of the individual numbers to `block` they
were rendering one-per-line on browsers that don’t support flexbox.
This commit changes these items to be floated and a predefined width. In
browsers that support it, flexbox seems to override these hard-coded
widths. It’s not quite as good as the flexbox solution because:
- it doesn’t adjust the widths in the nice way that flexbox does
- it’s hard-coded to expect 4 items (we don’t have this component with
any other number of items at the moment, so it won’t actually break
anything)
But it’s pretty much OK because:
- it’s a lot better than the before
- IE 8 and 9 combined only make up 5% of our users, and this will be a
declining number
- polyfilling flexbox would mean using Javascript, and we don’t serve
working Javacript to IE 8 users anyway
1. http://caniuse.com/#feat=flexbox
(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.
