We added this for the 25 May demo. We’re unlikely to need it again.
We’re also unlikely to need this library again, so this commit removes
the source and the code that creates it.
I've also tweaked some of the names to make them clearer e.g. that
the form is used to apply a change to a service.
I've constrained the scope of this change to avoid forms that may
be accessible by non-admins in the future.
This was a lot of code to be in a form and it's going to get even
more complicated with email branding pools. Moving it out means we
can also simplify the tests that target this code.
These are about to become a lot less similar to each other when we
add email branding pools. Note that the optional *args and *kwargs
weren't used anywhere.
I've often struggled to find the form associated with a particular
page due to the overlapping names e.g. "SetEmailBranding" sounds
more like the radio button form a user sees than "BrandingOptions".
Almost every form in forms.py also ends with "Form", so this also
makes the branding forms consistent with that naming convention.
I think it’s better to raise an exception and force us to fix it if we ever add a new auth_type, or use this formatter on something that isn’t a valid auth_type.
Co-authored-by: Ben Thorner <benthorner@users.noreply.github.com>
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.
Based on comments on the associated pull request,
(and my realisation that I was using flexbox
wrong):
https://github.com/alphagov/notifications-admin/pull/4171
Removal of flex-grow
I added `flex-grow: 1` to make the description and
status flex items grow to fill the container, at
least until they hit their `max-width`. They
already have `width: 100%` which achieves the same
thing so this removes it.
Using `width` doesn't work for flex-items with
flex-grow set above 0 because they will expand to
fill the space, whatever its value.
The intention for this line was always to
constrain how much these ones can grow to half the
space minus the gap between. `max-width`, which is
still honored by flex-items with `flex-grow` above
0, meaning they will expand up to that size.
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
This is consistent with all other methods: we clear the cache after
the actual change, not before it.
Since the new version of -utils, we're now catching redis exceptions
on delete, so this change has little effect on behaviour.
This was causing some tests for the "estimate_volume" endpoint to
fail due to the surprising way that form handles "''":
- The form is the exclusive user of the ForgivingIntegerField [^1].
- The field secretly/silently converts "''" to the integer 0 [^2].
If the validations fail, we don't want to surprise the user with a
"0" when they didn't enter one. The field already handles this by
massaging the values in the __call__ method that generates the HTML
for the form [^3]. However, there are two scenarios:
- User submits field with '' - converted to integer 0.
- User submits field with '0' - remains as a string.
In the case where "value" is "''", the parent class will use the
converted value from form.data instead [^4]. This seems to be an
oversight and so we get either the integer 0 (from form.data) or
the string '0' (from the value kwarg). Complicado!
Previously it was a fluke that we avoided replaying the integer 0
to the user; the previous commit removes the fluke. This fixes the
conditional to always use the data in the "value" kwarg if it has
been provided, as it's meant to override "form.data".
[^1]: 9f63449384
[^2]: a22b8cf684/app/main/forms.py (L364)
[^3]: a22b8cf684/app/main/forms.py (L393)
[^4]: a22b8cf684 (diff-a1c8d24b22d4478fe71f75fd43b71b18dd82aae97bc63de84473a6da1902909bR215)
A snippet of old code [^1] in "activate_user" was forcing us to
keep "user_details" in the session until the very last moment with
a "try / finally" combo. But "activate_user" already knows the ID
of the user: it's the argument we pass to the function.
None of the functions called by "activate_user" require the session
to have that key either i.e. it's definitely redundant.
It's unclear if we need to pop the key from the session in both
"verify" methods - there are no tests covering this behaviour. For
now, we can at least make the flow clearer by adjusting where we do
the "pop" and the assignment.
[^1]: bbc7b173f0 (diff-d12384ece5ad90e9b66063fd3ab170453788d36b7e0babf49ee016f0a880f251L71)
This is to fix a bug where a user creates an account but doesn't
complete registration, then they are invited to a service that
changes their auth to email_auth, and then when they try to
complete registration they are still asked for sms code.
It should save users some pain, and reduce number of support tickets.
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
Currently an integer of 0 doesn't get shown because it fails the
truthiness check in the govuk-frontend template [^1]. Note that
we can't just do str(value) as for None this would be "None".
[^1]: fd4952f1c0/src/govuk/components/input/template.njk (L51)
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.
Previously we weren't sure if the cause of this exception was what
the comment below suggested [1]. I've now verified this from:
Letter not found for service 0bd1d970-f11c-40e1-8319-4baefe6239d7 and file aa07ed06-3161-4795-93b3-b45d7c576af9
I checked that aa07ed06-3161-4795-93b3-b45d7c576af9 exists already
as a notification i.e. the comment is correct and we're not sending
users to a 404 page. It's possible there are other scenarios where
the comment is wrong, but I don't think it's worth keeping the error.
[1]: https://github.com/alphagov/notifications-admin/pull/4159
