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.
We’ve had some non-helpful answers to these questions, eg ‘3’.
This commit adds examples of the kind of response we’re looking for, to
help users write good answers.
If you’re a platform admin, you should go straight to the platform admin
page when you log in.
The all services page is just a crappier version of the same thing,
without all the stats, etc.
In research we’ve seen people mix up the service ID and API key because
they’re both 36 character UUIDs. We can’t get rid of the service ID
because it’s used to look up the API key.
Instead, we should change API key to be one long string, which contains
both the service ID, API key and (optionally) the name of the key. For
example:
```
casework_production-8b3aa916-ec82-434e-b0c5-d5d9b371d6a3-dcdc5083-2fee-4fba-8afd-51f3f4bcb7b0
```
We still need to keep the old, separate, key and service ID for a while
until people have updated their clients. But they’re now both on this
page, rather than on two separate pages, which should make for less
fussing anyway.
This shouldn’t be rolled out until the new clients are available.
- [ ] https://github.com/alphagov/notifications-python-client/pull/36
- [ ] https://github.com/alphagov/notifications-node-client/pull/10
- [ ] https://github.com/alphagov/notifications-ruby-client/pull/15
- [ ] https://github.com/alphagov/notifications-java-client/pull/38
- [ ] PHP????
This PR changes the flow to change an email address.
Once the user enter their password, they are told "Check your email".
An email has been sent to them containing a link to notify which contains an encrypted token.
The encrypted token contains the user id and new email address. Once the link is clicked the user's email address is updated to the new email address.
They are redirected to the /user-profile page.
Also in this commit is an update from flask.ext.login to flask_login.
These are out of date now and potentially misleading.
Adds a new error page for HTTP `410 GONE`. Looks like the 404 page, but
returns the appropriate error code to be a good web citizen.
You can’t properly use a normal key when your service is in trial mode.
It’s theoretically useful to create a live key in preparation for going
live. This utitily outweighs the confusion it causes for people creating
their first keys in trial mode.
We should just remove the confusing option.
I saw users in research going back into the whitelist to check that it
had saved because there’s no feedback.
This commit adds a flash message to confirm that the whitelist was saved
OK.
Why would a live servie need the whitelist? Because the team key will
also let you send to members of your whitelist (so this commit relabels
it to say so).
Basically:
- shows all the months from start of given financial year to now or end
of given financial year (whichever is earliest)
- shows a breakdown of free and paid text messages for each of these
months
Depends on:
- [x] https://github.com/alphagov/notifications-api/pull/699
The activity page was AJAXified in
https://github.com/alphagov/notifications-admin/pull/952 but this
didn’t take pagination into account.
So if you visited page 2, the contents of the page would be replaced by
Javascript with the contents of page 1. So you’d never be able to see
anything beyond page 1, expect for a brief fraction of a second when the
page loaded.
This commit makes sure the AJAX request uses whatever page parameter is
in the URL of the original page.
Platform admins should be able to see what’s going on with a service’s
API integration, including:
- messages sent
- contents of whitelist
- names of keys
They should also be able to revoke keys in an emergency.
The only thing they _shouldn’t_ be able to do is create new keys
(because then they’d be able to send messages as the service).
