If there is whitespace in the element containing the value to be copied
then Firefox[1] includes that space in the value it puts in the clipboard.
This is obviously annoying since `foo-bar` might be a valid API key where
`foo-bar ` is not.
This commit fixes that by using the `-` in Jinja to gobble whitespace.
I also looked at doing this in the Javascript, but the browser API for
selecting some text and copying it doesn’t give an obvious place for
using `String.prototype.trim()`.
1. Tested with Firefox 100.0 on Mac OS 12.2.1
When we changed the layout for each alert on the
current/past/rejected alerts pages to use flexbox,
we added a fallback for older browsers that set
text-align: justify on the container:
https://github.com/alphagov/notifications-admin/pull/4171
This has led to items in the list of areas an
alert will be sent to being laid out as justified
content when they were left-aligned.
These changes set the correct alignment.
At the moment if a user is pending we don’t show the ‘change’ link.
This is unhelpful because:
- there’s no way to remove this user
- there’s no way to change their phone number, if the reason that
they are still pending is because they’ve been unable to receive
the two factor code at the number they first provided
Direct string comparison in multiple places is prone to typos. It
also means that a consumer of the class needs to know that whether
a user is pending or active is held in the `state` property, which
is an implementation detail.
To keep the conditionals in the Jinja template more readable, this
commit moves the logic into a method on the model, where it can
be split over multiple statements and lines.
We fixed a problem with the focus styles of list
items in this pull request:
https://github.com/alphagov/notifications-admin/pull/4141
This missed out pages for areas with counties in
them. This adds the fix to those pages.
These changes also include some extra spacing
between the end of the list and the button which
is lost by the new styles we're giving the list
items.
So we don’t have to deploy a change on a Saturday.
In the future this could pull from the rates in the database, but while
that code is shifting around I didn’t want to touoch it. We’d also have
to think about caching so as not to have a non-authenticated route
hitting the database.
Note: I've removed the pricing assertion in the "0_free_allowance"
test as it's covered elsewhere - the value of the test is really to
check that we don't show the remainder if there never was any.
The previous, manual calculation could be incorrect depending on
which SMS rates the free allowance was attributed to.
The new field also supersedes the old "letter_total" bolt-on so we
can get cost information consistently for both types.
This will make the following changes clearer.
In the next commits we'll go into more detail about "billing_units"
and how it differs for SMS vs. emails and letters.
At the moment, we put the sms rate on the usage page for each
months billing data by taking the single sms rate for the year.
The assumption that there will be a single sms rate for the year is
no longer going to be true. Therefore, instead we take the sms
rate from the monthly data itself which tells us the rate for
a months worth of sent SMS.
the safe filter is quite dangerous - it allows HTML to be rendered as
passed through (the default action is to escape all html), so should
only be used with trusted input. Move it so we only apply it to fields
we specifically expect to have HTML in - in this case, some tables
contain links to other pages.
Also, clean up the variable names for some of these info tables, as they
didn't really make sense.
This makes the rendering the same as for "created_by_name" when the
data isn't present. It's a bit more complicated for "updated_at" so
I checked that it's implicitly covered by the tests, which fail if I
remove the "if" conditional for any of these fields.
