* Removed all govuk css
* Updated reference files
* Removing govuk js
* Fixed casing for modules, removed unused page
* Got more reference images
* Updated template page
* Removed govuk padding util
* Updated hint to uswds hint
* More govuk cleanup
* Commiting backstopjs ref files
* Fixed all unit tests that broke due to brittleness around govuk styling
* Added new ref images
* Final removal of govuk
* Officially removed all govuk references
* Updated reference file
* Updated link to button
* UI modernization
* Cleanup
* removed govuk escaping tests since they are no longer needed
* Fix CodeQL security issue in escapeElementName function
- Escape backslashes first before other special characters
- Prevents potential double-escaping vulnerability
- Addresses CodeQL alert about improper string escaping
* Found more govuk removal. Fixed unit tests
* Add missing pipeline check to pre-commit
* updated test
* Updated e2e test
* More update to e2e test
* Fixed another e2e test
* Simple PR comments addressed
* More updates
* Updated backstop ref files
* Refactored folder selection for non-admins
* Updated redundant line
* Updated tests to include correct mocks
* Added more ref files
* Addressing carlos comments
* Addressing Carlo comments, cleanup of window initing
* More cleanup and addressing carlo comments
* Fixing a11 scan
* Fixed a few issues with javascript
* Fixed for pr
* Fixing e2e tests
* Tweaking e2e test
* Added more ref files and cleaned up urls.js
* Fixed bug with creating new template
* Removed brittle test - addressed code ql comment
* e2e race condition fix
* More e2e test fixes
* Updated e2e tests to not wait for text sent
* Updated test to not wait for button click response
* Made tear down more resilent if staging is down
* reverted e2e test to what was working before main merge
* Updated backstopRef images
* Updated gulp to include job-polling differently
The API clients should just deal with calling the API and returning the
data from it.
Inferring things from the data is more logically done at the model
layer. But we couldn’t do that before, because we didn’t have a model
layer for jobs.
when clients are defined in app/__init__.py, it increases the chance of
cyclical imports. By moving module level client singletons out to a
separate extensions file, we stop cyclical imports, but keep the same
code flow - the clients are still initialised in `create_app` in
`__init__.py`.
The redis client in particular is no longer separate - previously redis
was set up on the `NotifyAdminAPIClient` base class, but now there's one
singleton in `app.extensions`. This was done so that we can access redis
from outside of the existing clients.
Calling `.set()` with `True` stores the byte string `'True'` which
cannot subsequently be decoded from JSON (because boolean values in
JSON are lowercase, ie `true`).
At the moment the dashboard does two API calls to find out if a service
has:
1. Scheduled jobs
2. Normal jobs
API calls are slow because they are synchronous, go over the network and
touch the database. We can’t cache these API calls because:
- a scheduled job could become a normal job at any time
- the statistics on a normal job are constantly updating
However there are plenty of services which don’t have any jobs, and
probably never will. And finding out if a service has any jobs is
reliably cacheable (because as soon as a service creates its first job
it has some jobs).
So this commit:
- refactors the way we get scheduled/normal jobs into the job_api_client
to make the view a bit slimmer
- makes an additional, Redis-wrapped call to find out if any jobs exist
before trying to get the jobs
This should result in a speedup on the dashboard, and can be used in the
future if there’s anywhere else we want to show or hide something
depending on whether a service has created any jobs (I have some ideas).
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The create job endpoint returns the data about the job with a `data:`
wrapper. This commit makes sure that, when the client is trying to
process a job which has just been created, it looks inside the `data`
wrapper.
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
It’s useful to know how many notifications we’ve handed off to our
providers. This is a measure of how complete the processing of the job
is.
This is important, because once the job processing is complete then you
can accurately reconcile the report with the CSV file that you’ve
uploaded.
Mutating dictionaries is gross and doesn’t work as you’d expect. Better
to have the function return a new dictionary instead.
Means we can be explicit that `created_by` is one of the allowed params
when updating a service.
