- Deleted /stylesheets folder
- Removed sass build from gulpfile
- Changed gov links to usa links
- Changed other govuk styles, like breadcrumbs
- Changed name of uk_components file to us_components
- Fixed a few tests that broke on account of the changes
* 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.
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.
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.
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.
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.
When looking at a notification you can either be coming from the page
of all notifications, or from a job. Currently the back link always
takes you to the page of all notifications.
This commit makes it a bit more sophisticated so if you’ve come from
looking at a job, you go back to the job.
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
The sending/failed/delivered thing:
- doesn’t map to the actual states of letters
- doesn’t respond quickly enough to give you feedback that something is
happening (because "sending" doesn’t even go to "probably delivered"
for a few days)
This commit replaces these 4 boxes with some more useful information:
- one number – how many letters were in the job in total
- when we estimate that the letters will be delivered
The status for each letter in a job will be the same for every single
letter (at least until we start dealing with returns).
It’s redundant to show this information over and over again. This commit
removes it.
This message is meant to indicate that generating the report is still in
progress. Saying 100% contradicts this because 100% sounds like
‘complete’.
Reason this is happening is because rounding 99.5 to 0 decimal places
gives you 100.
So let’s make sure it never gets above 99.0
Most of our tables are now lists which have:
- a thing you click on
- some secondary info about that thing underneath
- some extra numbers/status on the right hand side
Since these are so similar, they should share the same pattern, which
this commit does (using the `file-list` pattern).
Visually this means:
- the secondary text on the inbox becomes grey not black, for
consistency
- the status bit of the notifications tables bottom align like the
status of messages in the inbox
These both seem like OK changes to make for the sake of consistency.
We’ve removed the template on the jobs page, so you can no longer see
which template a job is about to be sent with.
This is removing information which might enable you to undo a costly
mistake.
I don’t think we need to bring back the whole template – giving its
name, and a link to it meets the need just as well.
In tables where we show rows and rows of information we used to give
some meta information about the notification, or at least as much as we
could give in the very limited space available.
This information is now on the notifications page, so the information we
show in these tables should just be whatever helps users identify the
right message. I reckon that this is:
- the content of the message for text messages
- the subject for emails and letters
This also makes these pages consistent with:
- the inbound SMS page
- the way the people’s inboxes work for their text
messsages/Whatsapps/emails
For consistency’s sake this makes the job page work the same way. It may
be slightly less useful here because on the job page every message is
sent from the same template, so will have broadly the same content.
