Changes OrganisationCrownStatusForm.crown_status.
This also effects NewOrganisationForm, which
inherits from OrganisationCrownStatusForm.
Because of that this commit also updates the
template used for the edit org crown status page,
which uses NewOrganisationForm for its form.
Changes the OrganisationTypeField class used by
OrganisationOrganisationTypeForm.organisation_type
OrganisationTypeField is also used by the forms in
/add-service:
- CreateServiceForm
- CreateNhsServiceForm
Because of that, this commit also includes changes
to the template for that route.
Note: this also moves where OrganisationTypeField
appears in app/main/forms.py so it can use
GovukRadiosField.
Includes changing form.enabled to use
OnOffField, for consistency with other on/off
fields.
OnOffField's data is a boolean, not a string, so
some of the logic using it needed to be changed.
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.
