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.
‘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.
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
Added extra radio button for 'org_banner' option
Updated service setting template to display appropriate text when option is selected
Updated tests to also accomodate new radio option
It’s useful to be able to play with the CSV upload thing and find out
how it works before you’re interrupted by the error telling you that
you’ve got as far as you can in trial mode.
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
Right now Notify restricts you to registering with a UK mobile number.
This is because when we built the user registration stuff we couldn’t
send to international mobiles.
However we can send to international mobile numbers, and it’s totally
reasonable to expect employees of the UK government to be working
abroad, and have a foreign mobile phone – we’ve heard from one such
user.
So this commit:
- changes all places where users enter their own phone number to use
the validation function which allows international phone numbers
- renames the `mobile_number` validation to `uk_mobile_number` to make
it explicit, and force it to break the tests if there’s somewhere it’s
being used that I haven’t thought of
We don’t want users in trial mode sending real letters. So we’ve
introduced an error message. This error message is also showing up when
users in trial mode and making a test letter (and having the knock on
effect of hiding the download button).
They should be able to make a test letter in trial mode, because it
doesn’t cost anything.
Debugging the DVLA markup stuff is quite slow, because it’s split
between the API and utils, and things that work in tests don’t always
work with real template content.
This commit adds us a private endpoint that will let us see what DVLA
markup will be generated for any template, enabling a quicker feedback
loop.
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 commit makes sure that the right permission choices are shown in
these pages:
- manage team page
- invite a user page
- edit permissions page
This is in order to make changing these pages easier (see subsequent
commits).
This commit makes the existing tests around user permissions less
verbose by using the new `client_request` fixture.
This fixture takes care of:
- setting up a service
- asserting that the response is `200`
It also tests that the page titles, some of which didn’t match with the
`<h1>`s, so this commit also fixes that mismatch.
As before the service manager will not be able to change the Text message sender once they have the inbound sms permission.
If the inbound sms permission is turned off the Text message sender setting is once more configurable by the service manager.
The inbound number remains bound to the service, but has "inactive", so that the number can not be used again.
There are quite a few more options that there used to be in the settings
page. This means it’s hard to find the thing you want to change.
Grouping options is a common way of making things easier to find.
Grouping by channel (text, email, letter) is something we do elsewhere
that seems to work pretty well.
