Uses the ServiceOnOffSettingForm.enabled.
Effects the following routes:
- /services/<service_id>/service-settings/switch-live
- /services/<service_id>/service-settings/switch-count-as-live
- /services/<service_id>/service-settings/permissions/<permission>
- /services/<service_id>/service-settings/permissions/broadcast
Includes changes to make the GOVUK radios
component render the h1 in the page. This is done
so the legend doesn't just duplicate the h1 and
is recommended in the design system guidance for
the radios component for pages that just ask you
for one piece of information.
https://design-system.service.gov.uk/components/radios/#how-it-works
Cloudfront, our CDN, sometimes decides not to gzip
assets. Because of this, we're going to gzip them
ourselves prior to upload instead.
This will involve:
1. adding gzipping to the make task that uploads
them
2. turning compression off in Cloudfront
There is already a pull request up for number 1:
https://github.com/alphagov/notifications-admin/pull/3733
Because deploying all this will, at some point,
create a state where Cloudfront is set to compress
assets that are already compressed, we need to
test that it doesn't re-compress them.
This adds a frontend build task that generates a
test asset which is:
- a copy of app/static/stylesheets/main.css
- renamed to include a MD5 SHA of its contents
- already gzipped
Once deployed, the test will be to:
1. download the asset from the live environment
2. unzip it
3. diff it against app/static/stylesheets/main.css
Raised by the service assessment accessibility
review as a problem for the footer due to it
having a mix of text and links.
This also makes it match the latest GOVUK Frontend
style.
When a browser loads a Notify page it does the following:
- DNS and TLS handshake for notifications.service.gov.uk
- download some HTML
- sees that the HTML needs to load some CSS
- DNS and TLS handshake for static.notifications.service.gov.uk
- downloads the CSS
We can speed things up a bit in modern browsers by parallelizing this
process a bit. Modern browsers support some HTTP headers[1] that allow
them to connect to other origins sooner.
After this change the steps are:
- DNS and TLS handshake for notifications.service.gov.uk
- receive response headers and simultaneously:
- download some HTML
- DNS and TLS handshake for static.notifications.service.gov.uk
- sees that the HTML needs to load some CSS
- downloads the CSS
1. https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch
On the uploads page we only show jobs which are within a service’s data
retention.
This commit does the same for when we’re listing the jobs for a contact
list. This matches the UI, which says a contact list has been ‘used
`<count_of_jobs>` in the last <data_retention> days’
> I'd find it useful to know mock_get_jobs mocks
> app.job_api_client.get_jobs here, perhaps through a comment. Reading
> it, I associated it with contact_list.get_jobs above.
Old contact lists can be:
- never used
- used, but so long ago we no longer have data about the jobs due to
retention settings
We show different messages in each of these cases. This commit
parametrizes the tests to ensure that both cases are covered.
Also makes the job a bit older so that both cases are logically possible
with the test data.
Because we’re be grouping jobs under their parent contact lists it’s
good to have some information ‘scent’ to help people find their jobs,
ie by clicking into a contact list. It also lets you see which list have
been used more than others, maybe because the update hasn’t been sent
to that group of people yet.
The hint text under uploads always says when they were used. For contact
lists this is a bit more complicated, since they can:
- never have been used
- been used multiple times
This commit makes use of the new fields being returned by the API to say
determine when these messages are relevant. They also let us
differentiate between a contact list that’s never been used, and one
that has been used, but not recently enough to show any jobs against it.
It’s a bit unintuitive that starting a job from a contact list makes a
copy of the file, which has no relationship to the list it was copied
from. This is more of an implementation detail, rather than something
that comes from people’s mental models of what is going on. Or at least
that’s what I hypothesise.
I think it’s clearer to show jobs that come from contact lists within
the lists that they were created from. By naming the jobs by template
this gives a clearer view of what messages have been sent to the group
over time.
The view layer shouldn’t be having to deal with converting dates as
strings. This is an artefact of how we send data from the API to the
admin app. The model layer should be responsible for turning JSON into
richer types, where it can.
The responses we get to paginated queries from the API are fairly
consistent, so we should be able to reuse the code that takes JSON
from the API and turns it into Python objects. This commits factors out
that code so that it is reusable (by inheriting from it).
The checkboxes component that lets you choose
which users have permission to see the folder is
currently using the noun of 'folder' in the
summary it generates.
This is because this page users the
TemplateFolderForm class, which defaults the
permissions to 'folder'.
This updates the field_label attribute, used by
the code that generates the summary, to 'user' to
match the type of permission.
