When trying to send letters using the API, the ‘team and whitelist’ key
is confusing. We don’t have addresses for your team members, nor is
there a whitelist for letter addresses. The actual behaviour is that
you’ll get an error if you try to use this key to send letters.
So, for services who have letters available, we should add a hint
telling users that team and whitelist is probably not the key they’re
looking for.
A common pattern we employ is `POST`-redirect-`GET`. To write tests for
this we often check that the URL of the redirect is what we’re
expecting.
With the way `client_request` is currently set up, there’s no way to do
this because the response isn’t exposed to the test.
So this commit adds an extra parameter which will let us test for
redirects.
We’ve seen from research (a long time ago) that the ‘manage service’
permission is too broad, and gives too much control to someone who only
needs the ability to edit templates. In other words, editing content
should be its own, separate permission, rather than being rolled up
into manage service.
Since this is already disaggregated on the API side, making this change
just means changing the mapping on the admin side and adding an extra
checkbox on the invite/edit page. Which is what this commit does.
So for now, an existing user who has the manage service permission gets
both manage service and manage templates (ie no change to what they can
do). Newly invited users will get to choose if they have both, either,
or neither.
- This is done using a new endpoint in the api.
- Removed the AddServiceForm in favor or using the ServiceNameForm
- Removed ServiceApiClient.find_all_service_email_from
We have a lot of services now. Mostly we want to look at what live
services are doing. So loading up the trial mode services every time
slows things – generating, rendering and using the page – right down.
This commit adds two new pages, one to view only live services, and one
to view trial mode services.
Adds a new endpoint that works like view template/view preview of
letter, so that this page works the same way it does for emails/text
messages (ie showing the full content of the message, including
personalisation).
We’re not worrying about redaction in letters for now.
The status won’t ever change from sending for letters. For now at least.
And even when we do come up with more useful statuses I’m not convinced
it’s useful to expose them to our admin users.
A more useful piece of information to show is when we think the letter
will be delivered.
If sending SMS is disabled for a service, it should not be possible to
add or modify SMS templates. If a user tries to do this, they should see
a different page with a link to go back. The same thing should happen
with email templates.
We’re frequently ending up with mismatched page titles on our pages
because:
- they’re hard to spot in the browsers tab bar
- new pages are often created by copy pasting old ones
It would be hard to write some kind of macro that spat out the h1
and the page title because they go into different blocks in the
parent template.
Instead, we can catch these mistakes by testing for them. Going
forward we should be using the `client_request` fixture for testing.
So it makes sense to put the page title test in here so that we
get it for free in every test – same way we do for testing response
codes.
fixup! Test for page titles in client request fixture
`test_utils.py` is actually a file for testing some utils, not
some utils for testing.
Test helper functions and fixtures are better placed in conftest,
and also means that we can use them in conftest.
If a template has the `redact_personalisation` flag set, then this
commit removes the personalisation from the notification before
rehydrating the template.
We’re doing this because we have a need to not show things like one time
passwords or two factor codes when we show the content of messages.
By passing through empty personalisation, and the `redact_missing` flag,
the `Template` instance will make use of the work done in:
- [x] https://github.com/alphagov/notifications-utils/pull/171
Works similarly to the delete template flow, because it’s a destructive,
one-way action.
Not on the edit template page, because it’s not something you want to be
considering every time you’re editing a template. And we saw that people
couldn’t find the delete button when it was on this page.
Adds a bit more CSS for the `dangerous` banner type, because the content
here is quite complicated. Breaking it into a list helps, but the
spacing didn’t look right, so needed some tweaking.
Can ship independently of the code that shows the redaction, but needs
the API first.
When we do a `POST` we almost always do a redirect straight afterwards.
`client_request` understands this, and expects a `302` by default.
However, if the `_follow_redirects` flag is set the status code returned
is that of the subsequent request – normally a `GET`, itself returning
`200`. Therefore the default expected response code would need to be
overridden.
Overriding this repeatedly would get pretty boring. Better to do it once
inside the fixture.
There are lots of services that only send emails, or only send text
messages. For these services, being able to filter the list of templates
but type is pointless – it won’t cut the list down at all.
This commit adds some logic to only show the navigation if the service
has some variety of template types.
Bug was happening because:
```python
bool(list())
>>> False
```
```python
bool((item for item in list()))
>>> True
```
i.e. generator expressions cast to boolean are `True`, even if they’re
empty – Python doesn’t evaluate them.
This was causing the functional tests to fail because it was taking too
long for any table rows to appear on the page.
We’ve had a few teams talk about wanting to go back and check what their
users are sending out, including the content of any placeholders.
We already provide this functionality through the API, this commit makes
it the default in the admin app too.
We couldn’t do this before because we didn’t have the individual
notification page.
It’s better to do this by re-hydrating the template than pulling the
content from the API, because things like letters have multiple areas
of content – this is more complex than what we can get from API at the
moment.
> Once an inbound message has been received, there should be a way to
> see the other messages in the system from the same service to the same
> number. Both in and outbound. Nice inbox/whatsapp stylee view or some
> such. This way the context of the reply is understood.
>
> Initially will only see the outbound template, not the actual message,
> but we’re going to change this for the rest (soon), so that you can
> always see the full message for all outbound.
