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.
This replaces the slider with an integer input for each provider.
Unfortunately showing a variable number of inputs isn't easy to
achieve in WTForms [^1], but we think this is the least worst way
to do it vs e.g. not using WTForms at all.
[^1]: https://github.com/wtforms/wtforms/issues/736
This isn't used and showing priorities when we only have a single
provider or where they have no effect is unnecessarily confusing.
Removing the form makes it clearer that there's only one way to
adjust priorities for domestic SMS providers.
If we add another email or international SMS provider in future,
we would need to rewrite the form here anyway as the priorities
need to be adjusted in tandem, not individually.
Using "primary" made sense when the other "secondary" provider was
new, but today we see them as equivalent and the terminology is a
bit confusing. In future we may add a third provider as well.
Users who have no mobile number set, users who are not on email auth
and users who are not on "Change mobile number" page should not
see the delete link.
This made it easier to debug a problem with the functional tests
due to the fixtures not working correctly [^1]. It's a platform
admin only convenience over knowing the page URL.
We may want to expose the top-level "/api-integration" page but
that will require more work to show which broadcasts were sent with
which key - currently it's oriented around "messages". For now I
think it's useful to see what keys a service has.
[^1]: https://github.com/alphagov/notifications-functional-tests/pull/411#pullrequestreview-920069799
On the ‘find user’ page it says ‘sms_auth’ instead of ‘Text message
code’.
This commit fixes that, and adds a handy formatter so it’s easier to do
the right thing in the future.
Having a grid in the click target stops the hint
and status text being clickable. This removes it
in favour using flexbox to position the elements
in a similar way.
Includes fallback styles for browsers that don't
support flexbox that positions the child elements
inline, laid out justified, to mimic the flexbox
positioning of justify-content: space-between.
Note: display is overriden on child items under
flexbox so setting display: inline-block is
ignored.
Daily volumes report: total volumes across the platform aggregated by whole business day (bst_date)
Volumes by service report: total volumes per service aggregated by the date range given.
NB: start and end dates are inclusive
So we do not have to go into the db when we need to change user
auth.
We do not allow this for users who use webauthn. We do not want to
enable security downgrade for those users.
Previously we duplicated the "something else" email branding form
on its own page and embedded in the choices form (if it was the
only option). See [^1] for how this looks - it's inconsistent.
This DRYs-up the "something else" form by bypassing the choices
form when "something else" is the only option. I've also tweaked
the "Back" button to be consistent with this behaviour.
Making this change also simplifies the choices form, which we'll
be adding pool options to shortly. I'd like to make the letters
form consistent, but let's see how emails pan out first.
Note that the choices form will now show a single radio button if
"something else" is the only option. I think that's OK as nothing
will link to the page, and the form still works.
[^1]: https://github.com/alphagov/notifications-admin/pull/4163#issuecomment-1050088088
In user research we quite often saw people accidentally scroll the
branding preview `<iframe>` when trying to scroll the page.
This is suboptimal because they:
- were confused why the page wasn’t scrolling
- lost visibility of the branding they were trying to preview because
it scrolled outside the bounds of the `<iframe>`
This means we:
- don’t have to copy and paste the `<iframe>` code to every place where
we use it
- can make changes to it in one place and have it apply everywhere
There are no changes to appearance of the 'Preview this alert' button or
what it does, but this stops a CSRF token appearing in the query
string when you click the button. We don't need a CSRF token - it's
a simple GET request which doesn't change any data. Before, we had a form
with `method="get"` but because we were using a `page_footer` a CSRF
token was being added.
We can replace both the `<form>` element and `page_footer` with a
`govukButton`. This means that we make a GET request with no CSRF token
without changing the appearance of the button.
Sometimes users ask us to delete their mobile numbers for them.
If those users are on email auth, they should be able to
delete their number themselves.
This will save them writing a support ticket and save us
going into the database.
This adds a preview of the current branding to users on the page where
they can select which new branding they want. Also includes a tiny
content change to match the new content doc for this story.
The pages you were redirected to if you selected either GOV.UK branding
or NHS branding used to give information about the branding and have a
button that submitted a Zendesk ticket. Now, we show a preview of the
new branding and the button applies it.
The `.email_branding_govuk` and `.email_branding_govuk_and_org` routes
shared a template since the content was the same - the only difference
was in the action of the button. However, since the pages will no longer
be so similar (e.g. the govuk page will show a preview) this splits them
up to use separate templates.
It may be the case that when the branding work is complete these pages
are fairly similar and we decided that one template between the two
endpoints is the best option again.
The current updateContent JS replaces the in-page
HTML with the HTML from the server the first time
an AJAX request is fired, even if the HTML from
the server has no changes. This is because the
code that compares the two operates on two
different things:
The HTML in the page is the component HTML, with
all the data attributes and the partial HTML
(marked with the 'ajax-block-container' class) as
its first child:
```
<div data-module="update-content" data-url="...">
<div class="ajax-block-container">
...
</div>
</div>
```
The HTML from the server only contains the
partial:
```
<div class="ajax-block-container">
...
</div>
```
The diffing code just sees them as different at
the top level so replaces the page HTML with the
partial from the server. This means all subsequent
diffs are between partial HTML and partial HTML so
only update on actual changes.
These replace the component with the partial, as
part of the component initialising. This means all
code that runs on an AJAX response will only
compare like-for-like so will result in actual
changes (or none at all), not just swapping one
element out for another.
Note: this commit also removes the
aria-live="polite" from the ajax_block component.
It has always been overwritten by the first
response so never announces anything to assistive
technologies. Removing it makes this more clear.
