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
Anyone choosing ‘NHS’ for their organisation type gets should get the
NHS branding. We don’t want to hard-code an ID for NHS branding anywhere
because it won’t be consistent between environments.
So instead we can say that anyone who chooses ‘NHS’ as their
organisation type should get whatever branding has `nhs.uk` as its
domain.
This allows us to easily manage the branding the same way we do other
brands, but gives us the efficiency of having it auto applied.
When a user creates a service we can take a pretty good guess at what
organisation they’re from.
For many organisations, especially local councils, GOV.UK branding is
not appropriate for their service. But right now every service:
- gets created with GOV.UK branding
- has to ask us to change it, even if they’ve already done so for other
services they run
This commit starts using the `domain` field on the email branding table
to lookup what email branding to assign to a service automatically,
where we’re sure there’s a sensible default.
Since we send all one off messages as priority now[1], we don’t need to
explicitly mark this template as being priority.
This stops the (potential) problem of people skipping the tour, still
having this template and then modifying it to send other messages,
potentially in high volumes from CSV files or the API. I don’t think
this is a real problem now, but worth cleaning this up.
Currently:
- 827 priority templates in the database
- 195 of which are not deleted
- 18 of which are not called ‘Example text message template’
- 3 of which look like genuine use cases, not from services that we run
[1]: https://github.com/alphagov/notifications-api/pull/1722
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
Different parts of government get billed slightly differently, and
there’s differences in how much money we’re allowed to give them.
Think these numbers are right, but should be double checked.
So that we can default services to their appropriate text allowance, we
need to find out what sector they're in. So let's start collecting that
from teams as they create new services.
I think Central/Local/NHS are the right options, but these can be easily
changed if not.
We’ve made a few changes to the tour recently, without changing the
help text on the left hand side of the screen. So the stuff you see on
the right side of the screen doesn’t quite sync up any more.
This commit adds an extra, introductory page that just shows the
template and a next button, which better matches the ‘every message
starts with a template’ help text.
The tour teaches you how Notify works by letting you do a thing and then
showing you the effect of the thing you’ve just done – a text message on
your phone.
This is not as effective if you don’t get the text message quickly. It
breaks the association you make between what you’ve done on the computer
and what’s happening on your phone.
Slow text message delivery can happen if you’re doing a big job. We can
get around this by making your text message use the priority queue.
This was observed in the pilot research session yesterday.
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
The test for non-gov.uk domains adding services is still relevant, but
probably makes more sense in `test_add_services.py`.
The others are no longer relevant now the ‘All services’ page has gone.
We reckon that:
- a ‘blank slate’ templates page is a better start
- the example template hurt more than it helped when it comes to
understanding placeholders
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
When you add a new service, it’s probably the one you want to do stuff
with.
When you get invited, the service you’ve been invited to is probably the
one you want to use.
This commit adds the ID of the new service or service you’ve been
invited to to the session.
There’s no content in the tour that’s specific to a service. And since
we can now take a pretty good guess at what service you last used, or
which service we should send you to if you only have one service,
there’s no need to make the URLs for the tour service-specific.
This also means that you don’t need to be logged in to see the tour
pages, and we have no good reason to only restrict these pages to users
with accounts.
https://www.pivotaltracker.com/story/show/116960703
We were using a bunch of different styles for form error messages,
including:
- having the name of the field in the error, or not
- can not/cannot/can’t (GDS content styleguide recommends using
contractions)
This commit adds a 3 screen tour, similar to those used on GOV.UK Verify
and Passports.
We guerilla tested this on Friday, and it really helped users to build a
mental model of how Notify works, so that when they’re playing around
with it they have a greater sense of what they’re aiming to do. This
makes concepts like templates and placeholders click more quickly.
https://www.pivotaltracker.com/story/show/116710119
of the name against a list of all service email_from fields.
Update find_all_service_names to find_all_service_email_from, which returns the email_from of all services.
Without the preview service name we probably have to go back to communicating
a bit more on the add service page. This commit brings back the two bullet
points about where the service name will appear, and tries to tie it into the
nice words that Matt Sheret wrote for us.
This page:
- confused users in research
- didn’t communicate what it was intended to (eg the generated email address,
how your service name would appear in messages)
This commit removes the page so that after typing in the service name the user
is sent straight to the dashboard for their new service.
This commit adds a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
This commit adds a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
Because the redirect after logging in checks the number of services a user has,
this now needs to be mocked.
Right now this means adding `mock_get_login` to any tests that need a login.
This must be one of the first mocks, so that it can be overridden by any use
of `mock_get_services`, for tests that specifically want to rely on a quantity
of mocked services, or their contents.
This is a bit fragile, but there’s already a TODO in the code to make it better
so ¯\_(ツ)_/¯
This commit moves user-related navigation into the proposition header (the black
bar) at the top of the site. It adds some custom SASS to override GOV.UK
template and align these navigation items to the right (because it looks
better).
It then removes the service chooser dropdown (and its associated SASS and JS) in
favour of a link alongside the user-related navigation items. ‘Switch service’
is the best language for this that we’ve come up with so far.
This means that the only way of adding a new service is from the `/services`
page. So this commit removes the redirect if you land on this page with only one
service (else it would prevent you from ever being able to add more).
