Make it clear that:
- In the case of text messages, it’s about who the message comes from
- In the case of emails, it’s about where the user will reply to
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
the update_user fn was used in two places, for things that are handled
fine by update_user_attribute. Reduce complexity in the API by killing
the PUT, which is more dangerous (might silently overwrite things that
shouldn't be, like "last_logged_in_at" etc).
Had to change the code not received mobile number form, and the
activate user function.
`prefix_sms_with_service_name` is a computed attribute on the service
model. It’s where we get the value from, and the API does some work to
get it from the database, or derive it from the default SMS sender.
It can’t be updated, because it’s not itself a database column.
`prefix_sms` is the name of the actual database column. This is the
thing that we need to update.
This will go away eventually.
At least one of our providers gives us messages with special characters
escaped, ie a newline comes through as `\n`, not a literal newline. We
shouldn’t be showing these backslashes to any of our users.
Python has built in codecs for dealing with encoding/decoding of
strings – see
https://docs.python.org/3/library/codecs.html#text-encodings
for details. Using these builtins is safer than trying to do anything
regex or parsing-based.
We’re extracting this from being determined based on what the sender
name is to its own setting.
This commit will let users set it independently.
Until the explicitly set it, it will still be determined based on
whether their default sender name matches the default for the platform.
In https://github.com/alphagov/notifications-admin/pull/1583 we changed
our Google Analytics settings to use newer browsers’ `sendBeacon`
feature. The advantage of this is that it
> [ensures] that the data has been sent during the unloading of a
> document [which] is something that has traditionally been difficult
> for developers
– https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
To transmit this data it uses a AJAX request (`XMLHttpRequest`)
underneath. AJAX requests are governed by the `connect-src` content
security policy (or the `default-src` if one is not present).
`connect-src`:
> Applies to XMLHttpRequest (AJAX), WebSocket or EventSource. If not
> allowed the browser emulates a 400 HTTP status code.
– https://content-security-policy.com/
Because we didn’t have one in place, `sendBeacon` requests to GA were
getting blocked in browsers that support content security policy (pretty
much everything better than IE11[1]).
1. https://caniuse.com/#feat=beacon
we currently store new account email verify tokens in the database, and
check against that to work out if they've expired. But we don't need to
do that, tokens have their own timing mechanism. So lets just use that,
and free up the database to do other things.
Also, standardised the forgot password, change email, and new account
email verification timeouts to all be an hour, from the config val
'EMAIL_EXPIRY_SECONDS'
if it 404s, because the service id doesn't exist, then it should die
gracefully (showing a 404 error page), rather than what it currently
does, which is die kicking and screaming with a 500
