werkzeug's internal workings keep files under 500kb in memory, and files
greater than 500kb as a TemporaryFile
(https://github.com/pallets/werkzeug/blob/0.11-maintenance/werkzeug/formparser.py#L38)
when we encounter a CSV or TSV, we call normalise_newlines, which invokes
`.read()`, however when we were passing straight into pyexcel, we called
`file.getvalue()` - this exists on BytesIO (small files) but not on
TemporaryFile objects (large files) - we were seeing 500 errors
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 polyfill we use for details/summary only renders the arrow if the
browser doesn’t natively support the feature.
The latest versions of Firefox _do_ now support the feature (after 5
years), but for some reason they don’t draw the arrow. So this commit
forces the arrow to be polyfilled in all browsers, and hides the browser
default one, for those browsers that do render it.
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)
