We’re removing it for performance reasons.
This means removing the old pages that edited the letter contact block
when it was stored directly on the service, rather than the current
model where a service can have multiple contact blocks.
This should speed things up by:
- less time waiting for big blobs of JSON to come from Redis or the API
- less time spent deserialising big blobs of JSON
‘Commonly used passwords’ is more specific, and avoids the terminology
‘blacklist’ which the National Cyber Security Centre explain to be
problematic:
> It's fairly common to say whitelisting and blacklisting to describe desirable and undesirable things in cyber security. For instance, when talking about which applications you will allow or deny on your corporate network; or deciding which bad passwords you want your users not to be able to use.
>
> However, there's an issue with the terminology. It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this. So in the name of helping to stamp out racism in cyber security, we will
> avoid this casually pejorative wording on our website in the future. No, it's not the biggest issue in the world - but to borrow a slogan from elsewhere: every little helps.
– https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white
This commit changes all the places where a user would see the term
‘whitelist’ in the content of page to say guestlist instead.
We’re removing the term ‘whitelist’ for two reasons. The first reason
is that we agree with the National Cyber Security Centre say:
> It's fairly common to say whitelisting and blacklisting to describe
> desirable and undesirable things in cyber security. For instance, when
> talking about which applications you will allow or deny on your
> corporate network; or deciding which bad passwords you want your users
> not to be able to use.
> However, there's an issue with the terminology. It only makes sense if
> you equate white with 'good, permitted, safe' and black with 'bad,
> dangerous, forbidden'. There are some obvious problems with this. So
> in the name of helping to stamp out racism in cyber security, we will
> avoid this casually pejorative wording on our website in the future.
> No, it's not the biggest issue in the world - but to borrow a slogan
> from elsewhere: every little helps.
– https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white
The second reason is that we’ve observed some users think that they have
to put recipients in the whitelist even when they’re already with in the
team. We think that the term ‘whitelist’ might be reinforcing this
mental model because of how ‘whitelists’ might work in other
applications.
We considered the following alternatives or concepts:
- Development
- Recipients
- Sandbox
- Extended team
- Smoke test recipients
- Allowed
- Nominated
- Bonus
- Additional
- Safe
- Team list
- Trusted contacts
- Designated people
- Guest list
- Team key list
We also considered not giving it a name, and explaining it as a nuance
of how the team key works. After mocking this up it felt more disjoined.
We think it’s still useful for the thing to have a name so that it’s
easy to refer to between the docs and the UI.
We like the term ‘guest list’ because:
- of how it sits with team members – members and guests in the abstract
- a guest list is a concept that a lot of people will be familiar with
– a list of people who can access a thing
- ‘guest’ is very different to ‘recipient’ – we want to mitigate any
confusion between this and the (emergency) contact lists
All the constructor of the service model is doing is setting a default
value of a property, this is more idiomatically expressed with a custom
property, and means we can get rid of the custom constructor entirely.
Since these two paragraphs sit on a blue background, they should have
white text. But this was getting overridden when the `govuk-body` class
was added in a previous commit, and the paragraphs appeared with black
text.
Previously these paragraphs were inheriting their colour from a parent
element. But a class applied directly to the element is more specific.
So this commit fixes the problem by being more specific again, by
applying the colour to the element, in the context of it’s parent’s
class.
All paragraphs should have class="govuk-body", or be otherwise
custom-styled. This commit adds some extra checks to our test fixture
that looks for paragraphs that don’t have any styling. Our test coverage
is pretty good, so this should check almost all pages, and prevent
regressions.
I’ve done this in such a way that it can be extended for other elements
(e.g. links) in the future.
Fixes a bug where we were calling a wrapper method when instead we
should have been calling the redis_client. This had resulted in no
actual calls to redis happening.
'Session expired' or similar makes it sound like a new error.
It could confuse the user and make them think the sign in didn't work
and that their session has expired again.
So we went with:
The change you made was not saved. Please try again.
Google’s documentation says:
> robots.txt is not a mechanism for keeping a web page out of Google. To
> keep a web page out of Google, you should use noindex directives
We’ve implemented a noindex directive now, so we don’t need to serve
robots.txt any more.
Reimplements https://github.com/alphagov/notifications-aws/pull/796
Since deploying alphagov/notifications-utils#736 I’ve been looking at
how members of the public are ending up on our support page. The vast
majority are landing on https://www.notifications.service.gov.uk/features/email
Previously we thought that they were clicking the ‘contact us’ link in
the page, which deep linked into the support journey, so we removed
these deep links in alphagov/notifications-admin#3451
But the tickets are still coming in, so I think that people are still
landing on this page, then going directly to ‘support’ in the top
navigation. So the next measure we have available is to try to stop
people from landing on this page in the first place. All the examples
I’ve looked at show people coming from Google to this page. By putting
the page’s URL in our robots.txt it should stop Google (and other search
engines) listing it in search results.
Google’s documentation says:
> robots.txt is not a mechanism for keeping a web page out of Google. To
> keep a web page out of Google, you should use noindex directives
A noindex directive means adding the following meta tag to pages that
shouldn’t be indexed:
```html
<meta name="robots" content="noindex" />
```
It’s also possible to set the directive as a HTTP header, but this seems
trickier to achieve on a per-view basis in Flask.
I’ve implemented this as a decorator so it can quickly be added to any
other pages that we decide shouldn’t appear in search results.
the upload preview page has a file_id - this corresponds to the file in
the transient pdf uploads bucket. However, if the user already hit send
(and then navigated back) the file's no longer in that bcuket, it's been
moved to the regular letters-pdf bucket. So the s3 get request fails. To
avoid this, simply redirect to the notifications page if the file isn't
in the transient bucket. This is better for the user as it'll stop them
trying to submit it twice, and will provide more clarity on the status
of the notification too.
When the admin app gets user objects from the API, these include a dict
of permissions by service for what the user can do to that services.
Permissions for inactive services are not included in the response as
per:
87cb6f2597/app/dao/permissions_dao.py (L66)
However, this causes a bug where a service is archived but cached user
data still tells us that the user has permissions to view the service.
This should not be the case and causes errors where users can still see
the archived service page, it's settings, and even request to go live
for it, because they are using old cached data for the user.
We solve this by deleting the users who are part of the service from the
cache.
We also delete the templates for this service from the cache as the
templates are also archived when we ask the API to archive the service
as per:
d95c0131e0/app/service/rest.py (L597)
Note, one decision I had to make was whether to delete the user cache
for just active team members or also invited users. Assuming an invited
user can't see the service until they've accepted their invite anyway, it
shouldn't make any difference whether we delete their cache or not.
