‘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.
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)
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
Have seen users complaining that they got an invitation email twice.
This is probably because they clicked the button twice even though they
think they only clicked it once.
Double form submission is a common issue on web pages, and there are a
number of different ways to prevent it. I’ve chosen to do it this way
because:
- temporarily, not permanently disabling the button means that this
addresses the double clicking issue without breaking things if the
user did, really want to click the button again deliberately (for
whatever reason)
- doing it with a `data` attribute, rather than the `disabled` attribute
means that the interaction behaviour of the button doesn’t change (
`disabled` buttons can’t be focused, for example)
Think this broke when we split the setting page up into three sections.
This forces the text to wrap onto multiple lines even if it doesn’t
contain spaces (for example an email address).
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.
