If we want someone to read something (ie that they need to have the MOU
signed), then the best way is to make them interact with it.
And if someone doesn’t have the MOU in place, then we need to know to
send them a copy. The best way of them telling us this is in this form,
rather than sending them to the generic contact form and have them
compose a message saying ‘please send me the MOU thanks’, which we
haven’t seen anyone actually do.
This was an early reckon feature. There were a few of problems with
it:
- it worked on the service, not just on the API keys as described
- it was back to front, ‘suspending’ a service set `active` to `True`,
reactivating it set `active` to `False`
- no part of the API actually respected the `active` flag on a service
The same intent can be acheived by either:
- revoking an API key
- having a platform admin put your service back into trial mode
So this commit removes the link and the code behind it.
The service API client was updating every attribute of a service. Which,
while kinda clunky, is fine…
…until something calling it doesn’t pass in every attribute of the
current service. It was then defaulting optional parameters to `None`.
Which resulted in a bug whereby every time a service was set to live,
its `reply_to_address` and `sms_sender_name` got overwritten to be
empty.
This commit changes the `update` method to only require the service ID,
and pass whatever other named arguments it received straight through to
the API. The API handles partial updates just fine (I think).
This commit:
- moves things around a bit on the request to go live page
- sticks a textbox in there
So when someone click the big green button, we will get a support ticket
that looks something like:
```
From Test User <test@user.gov.uk> on behalf of Test Service
(6ce466d0-fd6a-11e5-82f5-e0accb9d11a6)
---
We’ll send about 1000 text messages in the first month, and then 10,000
text messages per month after that. Usage of our service is about 50%
higher in March, at the end of the tax year.
```
Use the new version of the notifications-python-client. This version no longer adds the req and pay to the claims of the jwt.
The change is backward compatible so an older client that sends a JWT with the extra claims will pass authentication.
Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well.
The documentation has been updated to reflect this change.
https://www.pivotaltracker.com/story/show/116971293
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.
Each service on the list is linked to the dashboard page of the service.
The platform admin user can see/edit templates, see/invite users, see/edit service settings.
The platform admin user can not send messages, see/edit api keys and developer docs.
Actually this should be no op until whatever workflow will take place
in the real world is implemented.
For the moment just display flash message to say request being
processed and do nothing.
