If you sign in, don’t choose a service then navigate to a state page
then it’s possible `current_service` won’t be set, in which case you
shouldn’t be generating URLs that need `current_service.id`.
We used to give users the right version of the agreement by guessing
their organisation from their email address.
Now we do it by looking at the organisation of the service they’re
looking at.
In other words, users should only be downloading the agreement as part
of the go live journey, not outside it. This is because we think that
users will get confused if they download the agreement and:
- find there’s nowhere to physically sign it
- think that accepting the agreement is all they need to do to go live
Maintaining two paths to download the agreement also makes the code more
complicated, and makes it harder to update the content on these pages.
This makes it consistent that an option which contains more options has
a hint about how many options it contains.
Also adds a formatter to get us ready for 1,000 services 🎉
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
It:
- saves repetetive boilerplate code
- does some extra checks (eg checking for a `200` response)
- makes the codebase less confusing to consistently do the same thing in
the same way
This adds a preview pane which is visible when updating a letter brand.
If JavaScript is enabled, the preview pane shows on the set-letter-branding
page, and submitting the form saves updates the letter brand for a service
immediately. If Javascript is not enabled, there is a separate 'Preview email
branding' page which shows a preview of the brand and has a 'Save' button on it.
The value that means no branding (in the form) has changed from `'None'`
to `'__NONE__'`.
This commit:
- accounts for that value
- makes sure that no branding (ie plain GOV.UK) is still displayed when
no query argument is given
Some users are bookmarking the sign in page for quick access to their
Notify service.
If they’re already signed in when they used this bookmark they get
redirected. However the redirect isn’t very smart, because it just takes
them to their list of services. This isn’t great if they only have one
service.
This commit redirects them to the `show_accounts_or_dashboard` endpoint
instead, which does the work to figure out which page is most useful
to show someone when they sign in.
Also changing this for `/register`, although it’s less likely that
someone will have bookmarked this page.
Currently we have a bunch of users who aren’t signed in asking us for
the agreement.
This is bad because:
- it’s slower (for them) than just being able to download it
- it creates work for us
We can’t just offer the agreement to anyone, but we can offer to it to
anyone who’s signed in because we now let people self-select which
version to download when we can’t tell which one to give them.
we were seeing isort produce different outputs locally and in docker -
this was due to it having different opinions about whether the tests
module (ie all our unit tests) is a first party (local) or third party
(pip installed) import. It's a first party import, so by defining this
in the setup.cfg isort settings, we can force it to be consistent
between environments.
Note: I don't know why it was different in the first place though
We prefer people downloading the agreement if they can. If we don’t know
which agreement they should be using (ie we don’t know their crown
status) then we fall back to having them contact us.
We shouldn’t tell people on one page (the terms page) that we know about
their organisations agreement and then on the pricing page tell them to
contact us to find out what we know about the agreement.
So this commit adds the same logic from the terms page to the pricing
page, with wording that makes sense in the pricing context.
People are emailing us asking if their organisation has signed the
agreement. In some cases they have, so this is a waste of their and
our time.
This commit adds a bit of logic to the terms of use page to tell users
when their organisation has already signed the agreement.
Letters is now a mature enough feature that we should:
- be raising awareness amongst our users that it’s a thing we offer
- not have letters be a surprise to anyone creating a Notify account for
the first time
Shouldn’t be merged until:
- [ ] https://github.com/alphagov/notifications-api/pull/1600
Google tries to auto-generate a snippet of a site’s content to show in
search results. Currently it’s not doing a great job of this for Notify.
There’s a chance that if we give it better content in the site’s meta
description then it will use that instead. Worth a go…
The content is adapted from the blue box on the product page.
It’s 145 characters, which is within the 160 characters recommended[1]
It matches the content in the page, and contains words that users are
likely to be searching for (GOV.UK Notify, emails, text messages).
It’s only on the homepage, because it shouldn’t be duplicated across
multiple pages.
https://yoast.com/meta-descriptions/
Adds the new Using Notify view
Adds route to Using Notify page.
Add redirects for old pages
Removes the delivery and failure page as it's now in the Using Notify one
Removes the trial mode page due to Using Notify page
