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.
Friday at 4pm is easier to understand than 14 October at 4pm, especially
when the UI you’ve used to choose this time has talked about days of the
week.
Because users have difficulty getting back to the Notify admin
interface.
The `rel` attribute mitigates against [a nasty cross-domain
vulnerability](https://mathiasbynens.github.io/rel-noopener/).
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????
Was using the wrong attribute name on the instance of `RecipientCSV`
(needed to match 19df1eb4ef/notifications_utils/recipients.py (L156) )
The ‘can’t show file contents’ message wasn’t showing up, now it is.
We want to limit the number of rows someone can have in a job, because
it gets too slow to process the file otherwise.
This should be the first error that a user sees, because we can’t work
out if there are other errors until they’ve got the file down to a
processable size.
This also means adding a message to say that the file can’t be displayed
if it doesn’t contain any processed rows.
***
https://www.pivotaltracker.com/story/show/129830161
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.
The details of each notification were not being hidden on page load in
Firefox.
Firefox does not natively support the `<details>` element, so we
polyfill it.
Because of the way the polyfill is written[1]
1. There can’t be any `<div>` elements inside the `<summary>` (this
commit changes them to be `<span>`s instead, and adds CSS to make
sure they wrap as before)
2. The contents to be shown/hidden must be wrapped in a `<div>` (which
this commit adds)
***
1. 48fde82c72/public/javascripts/govuk/details.polyfill.js (L90)
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.
