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.
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.
Fixes the height of the component until it’s loaded so that it doesn’t
causes the page to reflow while it’s rendering the buttons.
Stops the options being shown and then immediately hiding on initial
page load.
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.
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.
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
