Then it’s one less cookie we have to get users to opt in to. We don’t
derive any value from Youtube setting cookies.
`youtube-nocookie.com` is a domain provided by Google for this purpose.
Users who have an API integration (and therefore have a way of passing
in a reference for each notification) can now search by that reference
(see https://github.com/alphagov/notifications-api/pull/2682)
This commit changes the label on the search box to tell these users that
this is possible, without changing the label for users without an API
integration, who might get confused by what ‘reference’ means.
It also makes the label consistently say ‘email address or phone number’
(ie email address is first) because this is our content style.
We chunk history entries by their YYYY-MM-DD date representation to
display them day-by-day.
However trying to convert a YYYY-MM-DD string into a timestamp is
unpredictable, and was causing our dates to be one day out (probably
because of midnight/daylight savings/general datetime horrors).
This commit changes the code to do the same thing as the history page,
which is look at the `updated_at` field on the first entry to get a
datetime object and from that the formatted date we show in the headings
on the page.
Makes these assumptions:
- we don’t care about history before 29th November 2019 at 11am (this
is when priority started to mean a proportion rather than a ranking)
- the priority of the second provider will always be the inverse of
the first provider
Which means the code is a lot simpler/actually does what you’d expect.
Their priority should always add up to 100%. Currently we have to ensure
this by hand. Adding this form means there’s no way to not set their
combined priorities to 100%. And it’s a bit more of an intuitive UI than
two textboxes on separate pages.
It’s not very useful to know the priority of one provider without
knowing the other. And these pages were never really designed, so they
weren’t super easy to understand anyway.
This commit adds a page that takes the first two text message providers
and shows their relative priority against each other.
It follows the design of the events page, as a pattern for showing a
log of historical events.
New units tests have not been written for this page because it is very like this will be refactor and probably a new template created for the page. Some design needs to go into this page.
But we needed something ready for user research.
accented characters rather than special characters. call them accented
as special is a bit wishy washy and doesn't explain what they actually
are. "Diacritics" is correct but too technical. Accented characters is
a happy middle ground
screanreaders struggle to distinguish accented letters, capitals, etc,
so by having a simple two column layout we can have the full unicode
glyph name, removing any ambiguity.
This makes it match the upload CSV page which has 30px of space between
the button and the following heading.
bottom-gutter-1-2 = 15px
form-group = 15px
15px + 15px = 30px
Re-upload button is only shown if file failed validation.
Change wording of re-upload buttons
Make test we test right buttons on letter upload preview page
Also remove double backlink
We can use the ‘Uploads’ feature to check if letters are printable now.
This code works in a completely different way, so if we kept it we’d
have to maintain two different code paths, and make sure that they
didn’t diverge.
Also deletes the related HTML templates.
`node_modules` isn't available in a live
environment so the `.njk` templates we're now
using from GOVUK Frontend need to go in the repo'
code.
Adds them in a new `app/templates/vendor` folder
to match how we do that in
`app/assets/stylesheets`.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
GOV.UK Frontend gives `<main>` different padding
on the top and bottom to us.
This adds our spacing to `<main>` for pages
without a side nav (except the product page which
is special) and to the row containing the `<main>`
and side nav sections on pages that have a side
nav.
GOV.UK Frontend's template wraps all content in a
`<main>` tag and puts it in the main column.
Some of Notify's pages need to reach out of the
main column (product page).
Some have several blocks of navigation before the
main content area.
This adjusts the blocks in all the templates
where this is the case so those conditions can be
met.
Now matches the block from the GOVUKFrontend
template.
This is the only page not suffixed by "GOV.UK
Notify" so has it's specific content for this
block.
Replaces the following blocks/variables with the
`footer` block filled by the `notify_footer`
macro:
- footer_top
- footer_support_links
Our current footer has a few differences
with the GOVUK Frontend one:
1. the columns of links and the meta links have no
headings, visible or structural
2. the line of text saying GDS built this prefixes
the meta links whereas theirs sits on a new
link, after them
Replaces the following blocks/variables with the
`header` block filled by the `header` component:
- header_class
- proposition_header
- global_header_text
- homepage_url
Also rewrites code that selects header nav items
The original code inserts a class name to mark the
nav item as selected.
The GOVUK Frontend header just needs a boolean to
be passed to indicate an item is selected.
This uses the `header_navigation.is_selected`
method, as before, but changes its return value to
a boolean.
`admin_template.html` is the base layout used by
all pages in the application.
This swaps out its dependance on govuk_template
for the version GOVUK Frontend provides.
Also renames blocks used in `admin_template.html`,
defined in both the old and new govuk_template
whose names have changed, as listed in:
https://design-system.service.gov.uk/styles/page-template/
Trial mode should let you preview the letter the same as live mode,
except for being able to actually end the letter.
Showing the recipient helps people understand how the feature works.
Since we’re only showing this page to team who are using the API we
don’t have to worry about explaining what’s going on in terms of the
spreadsheet any more.
This makes the page simpler.
