Most user will only have one reply to address. Which means they should
never have to worry about IDs. And if you only have one then you never
need its ID, because the last remaining address will always be the
default.
So IDs should only be shown when a service has created more than one
reply to address.
This required a bit of visual tweaking of the _user list_ pattern,
because its spacing wasn’t defined in a way that worked when only the
name of the thing, and not its details were shown on the page.
Something in a new version of GOV.UK Elements, Template, or Frontend
Toolkit has introduced a rules which removes padding for the last
column in a table.
This is undesirable in the case of email message previews.
‘Change’ as a label for the link is misleading, because this is also the
page you go to in order to get the ID of a given reply to address.
‘Manage’ feels a bit more general.
The first users of multiple email reply to addresses will be using the
API. This means that the need to be able to specify the ID of the reply
to address they want.
We chose to implement it like this instead of by passing the address in
directly because that means deploying code. For some teams deploying
code can take weeks, and we’d like to let teams have the flexibility to
make changes faster than this.
Same as for templates, you shouldn’t have to go to the _edit_ page in
order to get the ID. This means listing them on the page where you see
all the reply to addresses.
Listing the IDs like this means that it’s not really a table any more,
because the information isn’t organised in columns. So I think it makes
sense to reuse the pattern from the manage team page, which has a
similar relationship between the information.
I don’t think we’re getting any benefit from it. Especially since we’re
not running any Node code in production, but just using it to build the
frontend.
The downside is we keep getting these massive diffs which means we don’t
get an accurate line count on pull requests.
Followed instructions here:
https://codeburst.io/disabling-package-lock-json-6be662f5b97d
We didn’t like the nested conditional way of doing this. So this commit
refactors the way that permissions are set by:
- splitting it up into multiple, clearly named methods
- treating the list of permissions as `set`s, which they naturally are,
because you can’t have duplicate permissions (this removes a lot of
the complexity around having to test for membership before removing
a permission, for example)
It’s not either text messages, or emails, or both now – it’s any
combination of the three channels.
This commit adds ‘letters’ as an option on the request to go live page
by changing the radio buttons to a group of checkboxes, so the user can
choose as many or as few as they want.
This commit also does a bunch of housekeeping stuff around the tests for
this page, because they haven’t been touched in quite some time.
We didn’t make this self-service before because the pricing information
wasn’t published (ie we had to send it to services that asked for it).
Now that we publish pricing information in the app, there’s no reason
why services can’t make an informed decision about whether they want
international SMS or not.
So this commit:
- removes the platform admin button
- adds some radio buttons that our users can click with their mice
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.
