* Updated header and footer
* Moved files around and updated gulpfile to correct the build process when it goes to production
* Updated fonts
* Adjusted grid templating
* Adding images to assets
* Updated account pages, dashboard, and pages in message sending flow
* Updated the styling for the landing pages in the account section once logged in
If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created.
* We don't need the inset text to be inside `<div>` tags because the
component adds its own
* Replaced `bottom-gutter` with `govuk-!-margin-bottom-6` since this
change will be needed across the app at some point.
This adds spacing classes from the design system where necessary to keep
the spacing looking the same.
It also replaces the `<aside>` elements with a `<div>` on the edit
template pages. The accessibility audit noted that these were inside a
`<main>` element, so screen readers may not be able to navigate the
elements correctly.
Users sending text messages are sometimes unaware that long messages
will cost more.
Users sending broadcast messages need to be aware that there’s a
character limit, so they can take this into account when planning their
messages.
This commit adds an endpoint which counts the number of characters in
some template content, and returns a snippet of useful info about how
long the message is.
In subsequent commits we’ll be able to use AJAX to fetch this snippet as
the user types.
There’s a surprising amount of complexity in counting the length of
messages. So we’ll need to do this in Python because it would be too
convoluted to re-implement the length counting in client side code, let
alone ensuring it had parity with its Python equivalent.
Previously attempted in this commit by changing
the element to a <section>:
e815a73233
This broke the updateContent.js, that polls the
JSON endpoint for the partial and updates its
content with changes sent back. From what I could
tell, it broke it because the JS that does the
update gets the diff between the current partial
and the one sent in JSON and applies it to the
current one.
If the notification hasn't completed before the
page loads, the partial added to the page has a
<div> wrapping it, to initalise the
updateContent.js JS. This means the diff ends up
being between elements with a different level of
hierarchy:
Element 1:
<div data-module="update-content">
<div class="ajax-block-container">
...
</div>
</div>
Element 2:
<div class="ajax-block-container">
...
</div>
This seems to work OK when the partial
is a <div>, I assume because it's the same type of
element as the wrapper, but not when it's a
<section>:
Element 1:
<div data-module="update-content">
<section class="ajax-block-container">
...
</section>
</div>
Element 2:
<section class="ajax-block-container">
...
</section>
Because of all this, it's easier to just give it
the role of 'region'.
If it has an accessible name, we're essentially
giving it a grouping role so it should be a
section.
Note: it could also have a role="region" but
sections are a bit more HTML5.
All paragraphs should have class="govuk-body", or be otherwise
custom-styled. This commit adds some extra checks to our test fixture
that looks for paragraphs that don’t have any styling. Our test coverage
is pretty good, so this should check almost all pages, and prevent
regressions.
I’ve done this in such a way that it can be extended for other elements
(e.g. links) in the future.
There was a bug that displayed the error message with 2 red error boxes around the error message.
Also need another else to handle a new error message from the API, the old one can be removed after the API is deployed. But this can go first. I tested this branch with API master and the API branch with the change. I tested one off SMS and a CSV upload.
We had 7 classes in _grids.scss named `.column-...` which were being
used to give a certain column width. These worked by using `@include
grid column()`, which is now deprecated.
`.column-whole` and `.column-three-quarters` can be removed and replaced
with `govuk-grid-column-full` and `govuk-grid-column-three-quarters`
respectively. The other column classes don't have a direct replacment in
GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width`
SASS map in `extensions.scss` to add in extra widths, then use this with
the `govuk-grid-column` mixin to create new classes in for our custom
widths in `_grids.scss`
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
`recently_created` says it would just be looking at the `created_at`
field to see if it's been created recently. Technically this method
isn't doing that, whilst its behaviour would be similar, it's actually
different and maybe therefore a bit misleading.
Notifications won’t exist for a job if:
- it’s just started
- it started a long time ago (older than the retention period)
We have a bug where:
1. Job starts processing, puts notifications on queue
2. Job finishes processing, sets status to `finished`
3. First notification gets picked up off the queue and put in the
database
In between 2. and 3. it’s possible for a job to be finished, but also to
have no notifications. We’re saying this is because the notifications
have been deleted, whereas really it’s because they haven’t been created
yet.
This commit fixes that bug by introducing the concept of recency for
jobs.
‘Recent’ is defined as 1 day, which is:
- a lot longer than it takes to create any notifications
- a bit shorter than anyone’s retention time
N.B. `processing_started` is defined here:
879ba1d5f0/app/models.py (L1194)
It can be `None` for scheduled jobs that haven’t started yet.
By moving it from the view we reduce the complexity of the methods in
the view layer, so it’s easier to see what they do.
This also renames the variable `finished` to the property
`processing_finished` to disambiguate from the `job_status` field in the
JSON, which can also have a value of `finished`.
This follows the pattern of what we’ve done with services, users and
events.
It gives us a better interface to the data we get back from the API than
dealing with the raw JSON directly.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sesnsible model behind them.
You can click the blue boxes to filter the list of notifications. Once
the notifications have gone there’s nothing to filter, so we should just
show the numbers but without them being clickable.
Notifications could be missing because:
- none have been created yet
- they’ve been deleted
This commit adds separate error messages for each case, rather than a
less helpful generic one.
We work out how complete a job’s processing is by looking at how many
notifications have been created.
Later, we deleted all the notifications, according to the data retention
schedule. This makes it look like the job has gone back to 0% processed.
This commit accounts for this by not showing the % complete message once
a finished job has had its notifications deleted.
