Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
The yellow banner didn’t make this information much more noticeable,
and it made some people miss the request to go live link because it
wasn’t blue.
This commit brings the design back to where it was as of this PR:
https://github.com/alphagov/notifications-admin/pull/904
This is trying to resolve these confusions:
- that you’re in trial mode, which means you can’t have a live key yet (
or you can but it wont work, which is what we used to have)
- what does simulate mean
The create key page is the right place to resolve these confusions
because it’s where users are actively reading.
This commit also removes the trial mode banner from API integration
page because this where users _aren’t_ actively reading. A whole bunch
of users weren’t seeing this banner at all.
The implementation of the disabled API key options is kinda clunky
because WTForms doesn’t have a native way of doing this.
¯\_(ツ)_/¯
Fixes the height of the component until it’s loaded so that it doesn’t
causes the page to reflow while it’s rendering the buttons.
Stops the options being shown and then immediately hiding on initial
page load.
Categories before:
> Now, today, tomorrow, Friday…
Categories after:
> Now, later today, tomorrow Friday…
This reduces the ambiguity of ‘now’ vs ‘today’, and keeping the word
‘later’ suggests what this features is about.
This implementation here is a bit hacky, but it works…
The options for scheduling a job by time should be grouped by day,
because a long list of 96 options is not very usable.
On the server side, this commit generates label for the next 4 days in
a friendly format (ie today/tomorrow/Sunday/Monday)
The Javascript component for choosing a time was built in a kind of
old-school jQuery way, where it manipulated the elements on the page.
The complexity of introducing groups of options was just too much for
this pattern, because it involves storing a lot of state in the DOM.
This commit completely rewrites the JS to:
- read the initial options and groups from the HTML and store them
in the object
- use Hogan to completely re-render the UI from a series of Mustache
templates, each of which represents a state of the UI and takes the
inital options and groups
- filter the choices to show when the today/tomorrow/… buttons are
clicked
The polyfill we use for details/summary only renders the arrow if the
browser doesn’t natively support the feature.
The latest versions of Firefox _do_ now support the feature (after 5
years), but for some reason they don’t draw the arrow. So this commit
forces the arrow to be polyfilled in all browsers, and hides the browser
default one, for those browsers that do render it.
The details of each notification were not being hidden on page load in
Firefox.
Firefox does not natively support the `<details>` element, so we
polyfill it.
Because of the way the polyfill is written[1]
1. There can’t be any `<div>` elements inside the `<summary>` (this
commit changes them to be `<span>`s instead, and adds CSS to make
sure they wrap as before)
2. The contents to be shown/hidden must be wrapped in a `<div>` (which
this commit adds)
***
1. 48fde82c72/public/javascripts/govuk/details.polyfill.js (L90)
Basically:
- shows all the months from start of given financial year to now or end
of given financial year (whichever is earliest)
- shows a breakdown of free and paid text messages for each of these
months
Depends on:
- [x] https://github.com/alphagov/notifications-api/pull/699
It’s weird to be on a page that says ‘2 seconds ago’ and stays stuck
there.
We don’t want to AJAX the whole page because it would get in the way of
interacting with the list of notifications.
This commit adds the venerable jQuery Timeago[1] plugin to keep the
relative times accurate and fresh.
1. http://timeago.yarp.com/
Now that we’ve removed simulated notifications from the dashboard and
activity pages they’re not visible anywhere in the app.
While they should’t be visible to non-technical users, developers have
a real need for Notify to confirm that their code is doing what they
expect. This is needed especially when they’re just getting started with
Notify.
There’s no way of seeing this info from the API either, because a key
can only get notifications created with a key of that type.
It doesn’t make sense to make this a ‘mode’ of the dashboard or activity
because the information about notifications that developers need is
also different. So this commit adds up to 50 of the most recent
notifications sent via the API to the page that developers use as their
‘home’ page.
This also lets us explain the 7 days thing to developers via the
empty slate state of this area of the page.
Services who are in alpha or building prototypes need a way of sending
to any email address or phone number without having to sign the MOU.
This commit adds a page where they can whitelist up to 5 email addresses
and 5 phone numbers.
It uses the ‘list entry’ UI pattern from the Digital Marketplace
frontend toolkit [1] [2] [3].
I had to do some modification:
- of the Javascript, to make it work with the GOV.UK Module pattern
- of the template to make it work with WTForms
- of the content security policy, because the list entry pattern uses
Hogan[1], which needs to use `eval()` (this should be fine if we’re
only allowing it for scripts that we serve)
- of our SASS lint config, to allow browser-targeting mixins to come
after normal rules (so that they can override them)
This commit also adds a new form class to validate and populate the two
whitelists. The validation is fairly rudimentary at the moment, and
doesn’t highlight which item in the list has the error, but it’s
probably good enough.
The list can only be updated all-at-once, this is how it’s possible to
remove items from the list without having to make multiple `POST`
requests.
1. 434ad30791/toolkit/templates/forms/list-entry.html
2. 434ad30791/toolkit/scss/forms/_list-entry.scss
3. 434ad30791/toolkit/javascripts/list-entry.js
4. http://twitter.github.io/hogan.js/
We’ve found in research that developers have no idea they’re in trial
mode until they hit an error. And even then they don’t really know what
trial mode means.
So this commit:
- adds a message to the API integration page about trial mode
- puts it in a really yellow banner to draw attention to it
- adds the same banner to the settings page
This is like the ‘pill’ pattern that we use for filtering lists of
notifications. However it is meant for navigating between discrete
things, not a filtered view of the same list.
This is why is has a gutter between each item, and no selected state.
Turns out we already had a pattern about this on the dashboard, so this
commit also changes the dashboard to use the same code.
This commit changes the tables of notifications from 3 columns to two
columns. This is so the text has more room, so it doesn’t start
overlapping.
It also makes sure that if the recipient gets really long that it will
be cut off with an ellipsis, rather than overlapping…
I hypothesize that if a notification fails you probably don’t care when
it failed, just that it failed.
The way that we collapse column headings so that they don’t take up any
vertical space is by setting their `font-size` to zero. However this
seems to take them out of the flow of the document, so their top border
also disappears. This commit sets the `font-size` to the smallest
non-zero value to avoid this.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
Because the placeholder highlighting was defined in pixels it got
slightly out of line when it was used at larger type sizes, eg inside a
heading.
By using `em`s it will scale with the size of the type.
The previous text on this page around trial mode was a bit of a
mouthful. Also it only really made sense if you already knew what trial
mode was.
This commit tries to make it really explicit:
- that you’re in trial mode
- what it means to be in trial mode (copied from the trial mode page)
- where you go to not be in trial mode
Forgot to include this before.
The template expects it in `./images` but it should probably live in
`./images/email-template`.
This commit puts it in both places; we can clean up later.
We need to host these images somewhere. Let’s start off doing it in
the admin app, like we do for other email assets.
Eventually we should have a CDN in front of this.
Images lifted from
76ff2e0b6d/app/assets/images/crests
The pages with AJAX on were feeling quite sluggish, and it felt like
they were making the whole browser slow down.
Looking at the performance stuff in Chrome, the number of DOM nodes was
going up and up, which is weird because the number of things on the page
wasn’t changing. This was causing the page to consume more and more
memory in order to store all these nodes.
This is kinda beyond my understanding, but I tried a few things and it
looks like the browser was having a hard time garbage collecting the
temporary bits of DOM used to update the page.
By assinging these bits of DOM to variables before using them it seems
that the browser has an easier time cleaning them up.
Tables with a `layout` of `fixed` determine column widths from the
width of the column headings.
We weren’t setting the width of the first column heading, so our tables
were getting out of alignment.
