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.
When provided with inline configuration in a gulp task jshint will
still try to load a configuration file from the current directory
or the user's home directory. If user has a global .jshintrc file
that sets different linting options this could lead to `npm test`
output being different from the CI one.
jshint only uses the first file it finds, and .jshintrc in current
directory or any parent of the current directory takes precedence
over the user one, so moving jshint configuration from gulpfile to
.jshintrc should make `npm test` produce the same outcome regardless
of the user config.
`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
