> I'd find it useful to know mock_get_jobs mocks
> app.job_api_client.get_jobs here, perhaps through a comment. Reading
> it, I associated it with contact_list.get_jobs above.
Old contact lists can be:
- never used
- used, but so long ago we no longer have data about the jobs due to
retention settings
We show different messages in each of these cases. This commit
parametrizes the tests to ensure that both cases are covered.
Also makes the job a bit older so that both cases are logically possible
with the test data.
Because we’re be grouping jobs under their parent contact lists it’s
good to have some information ‘scent’ to help people find their jobs,
ie by clicking into a contact list. It also lets you see which list have
been used more than others, maybe because the update hasn’t been sent
to that group of people yet.
The hint text under uploads always says when they were used. For contact
lists this is a bit more complicated, since they can:
- never have been used
- been used multiple times
This commit makes use of the new fields being returned by the API to say
determine when these messages are relevant. They also let us
differentiate between a contact list that’s never been used, and one
that has been used, but not recently enough to show any jobs against it.
It’s a bit unintuitive that starting a job from a contact list makes a
copy of the file, which has no relationship to the list it was copied
from. This is more of an implementation detail, rather than something
that comes from people’s mental models of what is going on. Or at least
that’s what I hypothesise.
I think it’s clearer to show jobs that come from contact lists within
the lists that they were created from. By naming the jobs by template
this gives a clearer view of what messages have been sent to the group
over time.
The view layer shouldn’t be having to deal with converting dates as
strings. This is an artefact of how we send data from the API to the
admin app. The model layer should be responsible for turning JSON into
richer types, where it can.
The responses we get to paginated queries from the API are fairly
consistent, so we should be able to reuse the code that takes JSON
from the API and turns it into Python objects. This commits factors out
that code so that it is reusable (by inheriting from it).
The checkboxes component that lets you choose
which users have permission to see the folder is
currently using the noun of 'folder' in the
summary it generates.
This is because this page users the
TemplateFolderForm class, which defaults the
permissions to 'folder'.
This updates the field_label attribute, used by
the code that generates the summary, to 'user' to
match the type of permission.
This is no longer happening with the NVDA screen
reader, which had the issue, when testing in
Outlook.
The hack added as a temporary solution has now
been removed. It went live on 19 November 2020 at
2.20pm.
Proof of concept for the GovukRadiosField class.
Includes the removal of the a DataRequired
validator. This doesn't seem to be needed as the
RadioField superclass catches any submissions
without any data from field.choices in its
pre_validate method (which also outputs the
correct error message).
Since the focus background colour is now Design System yellow, the text
should be black for sufficent contrast.
This wasn’t happening because the `:link` selector’s definition had
greater specificity.
Aims to make the structure of their code more like
GovukTextInputField so this convention can be
extended for radios.
It does that by:
- moving the code in their widget methods out into
the govuk_checkbox_field_widget helper function
- moving the code that wraps the checkboxes
in HTML to make them collapsible into the helper
function
- remove GovukCheckboxesMixin in favour of having
the extend_params method as a stand-alone
function*
*The code is generic enough that it can be used
with other fields that share the same type of
data.
These changes also:
- don't alter the interface of any classes
involved
- don't break any tests
The _Long text messages_ section of the page is probably the most relevant place to talk about this – so users are aware of the double-characters before they see the table of message lengths.
Live services shouldn't be able to request to go live again. Once a
service is live we remove the option to go live from the Settings page,
but we still link to the page to request to go live from other places
e.g. the 'Get started' page. As a result, we've seen some services make
another request to go live when their service has already been live for
months - this change will stop that from happening.
We use a hack to extend the focus style of single
links in template list items (those not part of a
path of links).
This extended the 'focus box' downwards so it
covered the hint text below the link by the height
of the link (which is block-level).
Problems happen if the link wraps to multiple
lines. The hint is always on one line so the focus
looks over-extended.
These changes guard against those problems by
using the line-height instead of the block-height.
They include adding a Sass function to reference
the line-heights in GOVUK Frontend's Sass API:
https://frontend.design-system.service.gov.uk/sass-api-reference/#govuk-typography-scale
We look for `original_file_name` in the metadata now. Initially we were
still checking the query string too, but now that the change to add the
filename to the metadata has been deployed for a while there shouldn't
be any cases of the filename still being in a query string.
Since the `original_file_name` is not being added to the metadata in
`.check_messages` (it has happened earlier in the process) a few tests
are no longer needed.
The code was looking for `original_file_name` in the metadata for a
contact list, or the query string if it wasn't in the metadata. Now that
the change to use the metadata for the file name has been deployed for a
while e can stop looking in the query string for the
`original_file_name`.
