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.
There’s a lot of repeated code in our Jinja templates for the settings
page.
We already have a `boolean_field` component, but it’s not used anywhere
(it was just lifted from Digital Marketplace).
So this commit changes the `boolean_field` component to be useful for
our on/off use case, and wires it into the settings page.
GOV.UK Elements changed tables to be a larger font size here:
https://github.com/alphagov/govuk_elements/pull/185
This is good in principle (and a lot of our tables are 19px already).
However, the ones that aren’t are still 16px because there’s a lot of
info to fit on the page (eg when previewing someone’s CSV file).
Brings in:
- [ ] https://github.com/alphagov/notifications-utils/pull/128
This means that `RecipientCSV` will sometimes return the value of a cell
in a spreadsheet as a `list`, not a `string`. So we need to handle that,
rather than putting a Python representation (`['one', 'two', 'three']`)
on the page.
This commit handles it by putting a bulleted list on the page instead.
This breaks our model of showing the spreadsheet as it appears in Excel
or whatever, because we’re showing the aggregation of the columns into a
list. However:
- this is the easier thing to do for now
- it might actually be more usable because it keeps the table narrower
Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
In HTML you generally can’t nest an inline level element inside a block
level one, if you want your HTML to validate.
There were a couple of places where we were using a `<span>` as a
containing element:
- inside every table cell (think we inherited this from Digital
Marketplace)
- in the ‘pill’ navigation component for the selected tab
This meant that when we put components like big number inside these,
the resulting HTML was invalid, because big number is built with a bunch
of `<div>`s, which are block level.
This commit removes the use of a `<span>` tag in these places, and
replaces it with a `<div>`. Nesting block level elements in fine in
HTML.
This is mainly for the ‘check’ page where we show users the contents of
their spreadsheet.
> The structure of the table means that the first cell is treated as a
> column header, so moving through columns in row 2 for example
> associates the data 2 with 1 (column header) - this has no logical
> meaning
The first columns of our tables are always headings for the
subsequent columns, even though they go horizontally.
HTML has the `<th>` tag, which doesn’t just have to be used for headings
along the top of a table. So this commit changes the first column to be
a `<th>`.
This then allows us to style these elements differently, specifically
making them 50% wide. This makes pages like the dashboard align more
nicely.
This table had a lot of columns, which meant that some of them became
very narrow, wrapping the text awkwardly.
This commit groups some of the data into a chunk, which occupies the
first column.
When a table is showing the contents of a CSV file, it should look
something like a spreadsheet.
The minimally skeuomorphic way to do this is by adding row numbers.
This commit doesn’t
- make the row numbers monospace (it’s barely noticeable and doesn’t
reflect what actual spreadsheets do)
- make the first column heading ‘Row’ (again, doesn’t reflect how actual
spreadsheets work, and takes up more valuable space)
This takes the original prototype version of this page, and, using the same
fake data (ie nothing is wired up):
- adds an invite users page
- adds an edit (and delete) user page
Both these pages allow the user to set another user’s permissions.
This commit adds images for the ticks and crosses, so we have control over their
appearance.
This commit:
- adds the template to the jobs page (and puts it at the top of the send SMS
page) so that it consistently appears in the same place throughout the
journey
- put the real data about a job on the jobs page and on the dashboard
Copying what they’ve done on GOV.UK Pay, we should let users:
- generate as many keys as they want
- only see the key at time of creation
- give keys a name
- revoke any key at any time (this should be a one way operation)
And based on discussions with @minglis and @servingUpAces, the keys should be
used in conjunction with some kind of service ID, which gets encrypted with the
key. In other words the secret itself never gets sent over the wire.
This commit adds the UI (but not the underlying API integration) for doing the
above.
From the:
- dashboard
- activity page
This info will be confusing for users at the hack day, because it will say
they’ve already sent messages when they first sign up.
This involved changing the table macro to have a nice ‘no rows’ message.
Adds the pages and wires them together, so that it’s possible to click
through them.
The wording is not quite English, but attempts to be an rough description of
what the consequences are for each of the four actions.
This mocks out a data structure for a job’s messages, and renders this data:
- on the notification page, as a table, which links through to…
- …the page for an indidivual message
