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)
https://www.pivotaltracker.com/story/show/116052359
- add absolute numbers for failures
- make percentages accurate to 1 decimal place (50.0%)
- make error colour appear if failures go above 3.0%
- make error colour boolean (don’t interpolate between the colours)
The yes/no pattern didn’t work too well, because:
- it didn’t read naturally as a question and answer
- often users left them completely unclicked if they didn’t want to set
the permission (rather than clicking no)
This commit changes both the invite and edit user pages to use
checkboxes to set permissions. If also rewords these pages to read more
naturally, and explain what the permissions mean.
This meant changing some of the view logic around invites and
persmissions, and I ended up refactoring a bunch of it because I found
it hard to understand what was going on.
This commit adds two new sections to the dashboard
1. A banner telling you about trial mode, including a count of how many messages
you have left today, which is a restriction of trial mode
2. Panels with counts of how many emails and text messages have been sent in a
day, plus the failure rates for each
It does **not**:
- link through to any further information about what trial mode is (coming
later)
- link through to pages for the failure rates (coming later)
- change the ‘recent jobs’ section to ‘recent notifications’
Error messages were added to the yes/no fields on the invite user page in:
4c323a9a99
This commit fixes the margins and padding on these fields so they look
consistent with how we do validation errors elsewhere.
t
Makes uses of the additions to utils in https://github.com/alphagov/notifications-utils/pull/9
This commit strips out a lot of the complex stuff that the views and templates
in this app were doing. There is now a cleaner separation of concerns:
- utils returns the number and type of errors in the csv
- `get_errors_for_csv` helper in this app maps the number and type of errors
onto human-friendly error messages
- the view and template just doing the glueing-together of all the pieces
This is (hopefully) easier to understand, definitely makes the component
parts easier to test in isolation, and makes it easier to give more specific
error messages.
The email pattern looked a bit shonky when displayed in a narrower column. This
commit fixes it by making the email’s metadata (eg subject, from) into a table,
which it sort of is. This means that it is more flexible about the size of
container in which it sits.
As part of https://github.com/alphagov/notifications-admin/pull/187 the file
upload pattern was changed to auto-submit once a file had been picked. The
form that was submitted was, however, missing a CSRF token, as well as a submit
button for non-JS users.
This commit makes the file upload pattern self-contained, so that it will always
include a form with a CSRF token in a hidden input and a submit button, which is
then hidden when Javascript loads.
The ‘manage templates’ page was almost identical to the ‘send text messages’
page.
This commit consolidates them into one and makes them all hang together.
Part of this means tweaks to the javascript so that files upload as soon as
you’ve chosen them.
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 a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
This commit brings in the `Template` util, added here:
https://github.com/alphagov/notifications-utils/pull/1
It also does a fair bit of tidying up, which I’ve unfortunately squashed into
this one massive commit. The main change is moving 404 handling into the
templates dao, so that every view isn’t littered with `try: … except(HTTPError)`.
It also adds new features, in a prototypy sort of way, which are:
- download a prefilled example CSV
- show all the columns for your template on the 'check' page
This commit brings back the ‘link under the green button’ bit of the page footer
component.
Previous it had been changed to be a grey button. But there are use cases for
both, maybe even simultaneously.
Based on discussion with Pete.
Make the blue banner an ‘important’ banner (copied from Register to Vote, used
because it’s not as boxy and fits on the page better).
Remove the back button because you haven’t changed any data yet. If you need to
go back you can just press back or start again.
Make the filename stand out more.
Remove the ‘download example’ link. Will need to revist the best way of doing
this.
Make text messages consistently 2/3rd width.
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
This commit adds a very small Javascript module to autofocus a textbox on page
load. It should only be used once per page.
It also adds a parameter to the textbox macro which adds the attribute to
trigger autofocus.
For entering 2 or 3fa codes, we want a textbox that’s just over 6 characters
wide.
To do this, a width can now be passed to the textbox macro. The possible widths
are the same as those provided by GOV.UK Elements, and in the same format (eg
1-4, 1-2, 2-3…)
This commit also adds a new width (5em) which is suitable for 3fa codes, and
adds it to the verify page.
The grouping on this page was weird because these links were two far away from
the associated textbox, and too close to the next textbox.
This commit adds them as parameters to the textbox macro, which means their
relative spacing can be controlled exactly, and thus reduced.
- remove black border from banner
- make banners have internal columns
- make nav 2/3rd width, 19px text and more spaced out
- only show the ‘restricted mode’ banner where it’s needed
- rename ‘restricted mode’ to ‘trial mode’
For the hack day, we should only let developers use the platform in restricted
mode. This commit adds a banner telling them this.
Can’t get the app running locally, so fingers crossed it actually looks how
I imagine it’s going to look…
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.
A previous commit removed these to differentiate between this page and the
manage templates page. It turns out that we do want previews on this page
because:
- the users for the two pages might be different—they might only be allowed to
do one or the other depending what permissions they have
- it’s useful to see what the placeholders in the message are before uploading
a CSV, to make sure the CSV has the correct column headings
This commit re-adds the message preview with a simpler UI. Discussed with
@antimega and we both agreed that the speech bubble tails on the messages should
go.
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.
This commit adds a component for showing an API key. Usage:
```jinja
{{ from 'components/api-key.html' import api_key }}
{{ api_key('e1b0751388f3cd0fc9982c701acdb3c2') }}
```
Depending on the user’s browser, it works in three different ways.
No Javascript
---
The API key is shown on the page.
Older browsers with Javascript
---
The API key is hidden, and users can click a button to reveal it.
Newer browsers that support copying to clipboard without Flash
---
As above, but when the key is shown there is a button which copies it to the
clipboard. This is acheived by using
[this polyfill](https://www.npmjs.com/package/query-command-supported)
to reliably detect browser support for the ‘copy’ command.
The styling of the component is a bit different to the initial sketch. I think
a grey button works better than green. Green feels like it’s going to take you
somewhere else.
This is a link not a button because:
- it’s less prominent—delete is an infrequent action
- it’s a two-step process, and only the second part changes any data (so it has
a button)
If the templates page contains text messages and emails then there’s two ways it
could be structured:
- into two sections, all text messages first, then all emails
- emails and text messages interleaved, sorted by date
I think the second one is better. Imagine a situation where you mostly do emails
but have a few text messages. You’d have to scroll past the text messages to get
to your emails. Every time.
I reckon that the most commonly accessed templates will be the most recent ones.
This macro:
- accepts a WTForm form field as a parameter
- renders a form field which follows the GOV.UK Elements patterns, both visually
and in markup terms
It then changes any page which uses either:
- the old, non-WTForms macro or
- the old, WTFforms `render_field` macro
…to use this new macro and removes both of the old ones.
It also adds the option to display hint text above the textbox.
Message status was almost identical to banner, visually and semantically.
This consolidates the two into one component.
This means adding an extra parameter which controls whether or not the banner
has a tick (with and without a tick are the only two variations currently).
Found a way to create the token that does not need to persist it to the database.
This requires proper error messages, written by people who speak menglis good.
