- API will now send through `created_by_name` instead of `created_by`.
- API will always send through `current_month_billable_sms` but this can
now be `0` instead of `None`.
Doing a lookup with `step_index - 1` means that on step `0` we were
looking up `placeholders[-1]`, ie we were making people fill in the last
placeholder first.
Fixing this reintroduces the bug fixed by this pull request:
https://github.com/alphagov/notifications-admin/pull/2551
So this commit also re-fixes that bug but in a different way.
Usually the service’s organisation and the user’s current organisation
will be the same. But this won’t be the case when:
- someone with a non-government email address is looking at the page
- someone from our team, as a platform admin user, is looking at the
page (it will show Cabinet Office instead)
This commit fixes these problems by explicitly looking at the service’s
organisation. We couldn’t do this previously because when this page
wasn’t service-specific `current_service` was not guaranteed to be set.
Our usability testing found that jumping out of the service when going
to download the agreement made it difficult for people to find their way
back to the ‘Request to go live’ page.
This commit adds a duplicate, service-specific versions of these pages
which have the same content but:
- keep the service navigation
- have a link back to the ‘Request to go live’ page
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
When a user's email address is updated, we not allowing it to be changed
to a non-government email address. We now allow a non-gov email address
to be changed to another non-gov email address. Government email
addresses still cannot be changed to non-government email addresses.
Also fixes the link in the error message on the ChangeEmailAddress form -
this was being escaped before.
Every time someone adds a new service we ask them what kind of
organisation they work for.
We can look this up based on the user’s email address now. So we should
only ask the question if:
- we don’t know about the organisation
- or we haven’t set what type of organisation it is (this shouldn’t be
possible on productions because we’ve populated the column for all
existing organisations and it’s impossible to add a new one without
setting it
We’re deprecating storing the domain as text on a branding in favour of
a database relationship between branding and organisation.
We need to do this now in order to remove the validation on these fields
(which depends on the data in `domains.yml`)
Settings looked at `domains.yml` when users were making go live requests
or email branding requests.
This will allow us to remove the `domains.yml` file, by using
information about organisations that is now stored in the database
instead.
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
We should audit when a service manager changes a user profile that is not
their own. This can be recorded in our events table, which is currently
only used to record successful logins.
This adds two new types of event, `update_user_email` and
`update_user_mobile_number` which store the
- browser fingerprint
- IP address
- user id of the user being updated
- user id of the service manager making the change
- original email address and new email address (for `update_user_email`
events)
- original mobile number and new mobile number (for
`update_user_mobile_number` events)
