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.
we have a hunch that some session related issues that we've seen over
the last few weeks might be related to weird race conditions where
cookies set by subresources (image previews of letters on the send flow)
arrive just as the img request is cancelled because the user has clicked
on a button to navigate to a new page, but still manage to set the
cookie? We're not entirely sure what's going on, but we've got a hunch
that not setting cookies on image fetches sounds sensible. Images are
always loaded as a subresource (ie: through a `src` tag in an html
element), so they should never need to change the cookies, so this seems
sensible. We've done this by creating a new blueprint that doesn't set
session.permanent, and doesn't call `save_serivce_or_org_after_request`
either.
cookies are sent back to the browser if:
`sesion.modified or (session.permanent and 'REFRESH_EVERY_REQUEST')`
(where the latter is a config setting).
Turning off REFRESH_EVERY_REQUEST (which is True by default) means that
we will only update the sesion if it's been modified. In practice,
literally every request is modified in the after_request handler
`save_service_or_org_after_request`. This is accidentally convenient,
as it guarantees that we'll still send back the cookie normally even
though refresh_every_request is disabled. Sending back the cookie
updates the expiry time (20 hours), so we need to keep doing this to
preserve existing session timeout behaviour.
The current method reports `0` in Safari, whatever
the scroll position.
Some testing across our browser matrix shows:
1. this is also the case on IOS
2. browsers in the matrix all support
`$(window).scrollTop()`
https://scroll-position-test-page.glitch.me/#results
This changes the method to use
`$(window).scrollTop()` instead.
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.
`node_modules` isn't included on live so all
macros need copying across into the repo' code.
This adds the back-link component to the list of
macros to be copied across in `gulpfile.js`.
It also adds the files copied across as a result
of running the frontend build into the repo'.
`app/.gitignore` existed to list anything that we
wanted ignored from the repository but not listed
in `.cfignore` (which just symlinked the
`.gitinore` at the root).
Now `.gitignore` and `.cfignore` are split, this
is no longer necessary.
