This is trying to resolve these confusions:
- that you’re in trial mode, which means you can’t have a live key yet (
or you can but it wont work, which is what we used to have)
- what does simulate mean
The create key page is the right place to resolve these confusions
because it’s where users are actively reading.
This commit also removes the trial mode banner from API integration
page because this where users _aren’t_ actively reading. A whole bunch
of users weren’t seeing this banner at all.
The implementation of the disabled API key options is kinda clunky
because WTForms doesn’t have a native way of doing this.
¯\_(ツ)_/¯
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.
you can get in with either "manage_templates" or "send_letters"
also improve running of a bunch of tests, by parametrising rather than
looping and by cleaning up some mock imports
If you’re looking back at a job that was scheduled and has now been sent
it’s more useful and consistent to know what time it went out. The time
it was uploaded at is a bit arbitrary once it’s sent.
The only time the uploaded time is relevant is when the job is still
waiting to be sent.
Slightly fiddlier than it sounds because we never want to show
‘uploaded by’ for a job that hasn’t been scheduled because it almost
immediately changes to ‘sent by’. This flickering of the UI is
undesirable.
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.
Categories before:
> Now, today, tomorrow, Friday…
Categories after:
> Now, later today, tomorrow Friday…
This reduces the ambiguity of ‘now’ vs ‘today’, and keeping the word
‘later’ suggests what this features is about.
This implementation here is a bit hacky, but it works…
The options for scheduling a job by time should be grouped by day,
because a long list of 96 options is not very usable.
On the server side, this commit generates label for the next 4 days in
a friendly format (ie today/tomorrow/Sunday/Monday)
The Javascript component for choosing a time was built in a kind of
old-school jQuery way, where it manipulated the elements on the page.
The complexity of introducing groups of options was just too much for
this pattern, because it involves storing a lot of state in the DOM.
This commit completely rewrites the JS to:
- read the initial options and groups from the HTML and store them
in the object
- use Hogan to completely re-render the UI from a series of Mustache
templates, each of which represents a state of the UI and takes the
inital options and groups
- filter the choices to show when the today/tomorrow/… buttons are
clicked
If you want to send a job on Monday morning, you should be able to
schedule it on Friday. You shouldn’t need to work on the weekend.
96 hours is a full 4 days, so you can schedule a job at any time on
Friday for any time on Monday.
We’ve checked with the information assurance people, and they’re OK
with us holding the data for this extra amount of time.
This commit changes the choose time form from showing one radio button
for each of the next 24 hours to one for each of the next 96 hours. It
changes the labels from ‘9am’ to ‘Monday at 9am’ so it’s clear which
day you’re choosing.
The test for non-gov.uk domains adding services is still relevant, but
probably makes more sense in `test_add_services.py`.
The others are no longer relevant now the ‘All services’ page has gone.
also added tests for the various hiding logic points
also added new logged_in_client in conftest - so you dont need to
patch all those stupid API calls for get user and get service
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
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.
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.
