These tests make sure the sub-categories shown
when a category is selected are right but the
comparison looked for a direct match between the
labels for both types.
This looks for the category label in the
sub-category label instead, ie.
'Today at' in 'Today at 1pm'.
...instead of
'Today at' === 'Today at 1pm', which will always
fail.
Different emergencies will need broadcasts to last for a variable amount
of time. We give users some control over this by letting them stop a
broadcast early. But we should also let them set a maximum broadcast
time, for:
- when the duration of the danger is known
- when the broadcast has been live long enough to alert everyone who
needs to know about it
This code re-uses the pattern for scheduling jobs, which has some
constraints that are probably OK for now:
- end time is limited to an hour
- longest duration is 3 whole days (eg if you start broadcasting Friday
you have the choice of Saturday, Sunday and all of Monday, up to
midnight)
At the moment the first AJAX call is triggered as soon as the page
loads. We then look at its response time to work out how long to wait
until making the next call.
This isn’t great because:
- stuff is unlikely to have changed straight away, so it’s a waste of a
call
- while the DOM is being updated it seems to introduce a delay in
clicks on links, which is either more pronounced or more noticeable
when it’s happening straight away, making the UI feel less snappy
I chose a value of 2 seconds as a rough proxy for the minimum time we’d
expect to see a notification go from created to delivered. Median
time-to-delivered was 2.9 seconds when we analysed it for
https://github.com/alphagov/notifications-admin/pull/2974#discussion_r286101286
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
We had 7 classes in _grids.scss named `.column-...` which were being
used to give a certain column width. These worked by using `@include
grid column()`, which is now deprecated.
`.column-whole` and `.column-three-quarters` can be removed and replaced
with `govuk-grid-column-full` and `govuk-grid-column-three-quarters`
respectively. The other column classes don't have a direct replacment in
GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width`
SASS map in `extensions.scss` to add in extra widths, then use this with
the `govuk-grid-column` mixin to create new classes in for our custom
widths in `_grids.scss`
Includes:
- make 'remove team member' link, on edit member
permissions page, destructive
- convert missed links on /features pages
- convert missed links on /using-notify/guidance and sub pages
- give links in browse-lists back their size and
weight (needed for lists of live and trial
services on Platform Admin)
- give links on Platform Admin inbound numbers
page back their size and weight
- update links in JS tests
Includes:
- make 'remove team member' link, on edit member
permissions page, destructive
- convert missed links on /features pages
- convert missed links on /using-notify/guidance and sub pages
- give links in browse-lists back their size and
weight (needed for lists of live and trial
services on Platform Admin)
- give links on Platform Admin inbound numbers
page back their size and weight
- update links in JS tests
As part of updating the stylesheet, moved `.button-secondary` to the
global stylesheet, since this is not related to list entries but instead
affects all buttons with that class (this class wlil be removed once all
the buttons are using the new macro).
We have been clearing all the Google Analytics
cookies on each page request.
It is now possible for a user to consent to having
Google Analytics cookies so this should have been
checking for that before deleting them.
This makes that change, with tests for those
scenarios.
https://jestjs.io/docs/en/configuration#testurl-string
Affects all DOM APIs that return information about
the URL, for example window.location.
Why:
We now have tests for setting/deleting cookies.
Tough-cookie, the library JSDOM uses for cookie
handling cookies doesn't allow setting cookies
with `domain=localhost`. This is correct by
RFC6265, the standard it follows, as domains must
have 2 or more `.`s in them.
The only way to set a cookie on `localhost` is to
leave out the `domain` attribute.
The code we are testing sets and deletes cookies
set on specific domains so using `localhost` is
out.
We also cannot just set/delete cookies on the
domains used as cookies are required to match the
domain of the current page.
The solution we are left with is to set the
current page to one from production and make sure
each cookie is set relative to that domain.
Note: this introduces `testURL` in isolation to be
sure it doesn't break any existing tests.
app/assets/javascripts/errorTracking.js sent
events to `window.ga`.
This extends the API of `window.GOVUK.Analytics`
to include support for sending events so all
calls to `window.ga` can use it instead of direct
access.
This use of `window.ga` was missed from the
initial work on `window.GOVUK.Anaytics`.
Includes:
- tests for the analytics interface ported from
GOVUK Frontend Toolkit
- tests for the cookie banner that appears on all
pages except the cookies page
- tests for the cookies page JS
- tests for the hasConsentFor function
- adding a deleteCookie helper to remove
cookies during tests
- polyfill for insertAdjacentText
The last one is because JSDOM doesn't support
insertAdjacentText but our target browsers
do. This polyfill also includes one for
insertAdjacentHTML.
app/assets/javascripts/errorTracking.js sent
events to `window.ga`.
This extends the API of `window.GOVUK.Analytics`
to include support for sending events so all
calls to `window.ga` can use it instead of direct
access.
This use of `window.ga` was missed from the
initial work on `window.GOVUK.Anaytics`.
Includes:
- tests for the analytics interface ported from
GOVUK Frontend Toolkit
- tests for the cookie banner that appears on all
pages except the cookies page
- tests for the cookies page JS
- tests for the hasConsentFor function
- adding a deleteCookie helper to remove
cookies during tests
- polyfill for insertAdjacentText
The last one is because JSDOM doesn't support
insertAdjacentText but our target browsers
do. This polyfill also includes one for
insertAdjacentHTML.
