* if the service issuing the invite does not have permission to edit
auth types, don't let them do anything. This will stop them turning
existing email_auth users back to sms auth
* if the user hasn't got a mobile number, but the invite is for sms
login, don't do anything either. They won't have a phone number if
they signed up via an email_auth invite previously.
in these cases, we accept the invite and add the user to the service
as normal, however, just don't update the user's auth type.
If we’re going to ‘disable’ radio buttons then we should always tell
users why the radio button is disabled.
This is what we found with the API key choices anyway.
Google tries to auto-generate a snippet of a site’s content to show in
search results. Currently it’s not doing a great job of this for Notify.
There’s a chance that if we give it better content in the site’s meta
description then it will use that instead. Worth a go…
The content is adapted from the blue box on the product page.
It’s 145 characters, which is within the 160 characters recommended[1]
It matches the content in the page, and contains words that users are
likely to be searching for (GOV.UK Notify, emails, text messages).
It’s only on the homepage, because it shouldn’t be duplicated across
multiple pages.
https://yoast.com/meta-descriptions/
We have a sort of principle that when clicking a link, the page you land
on should be titled the same as the link you clicked.
This also reduces unnecessary repetition between the page title and the
form label.
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.
flask-script has been deprecated by the internal flask.cli module, but
making this carries a few changes with it
* you should add FLASK_APP=application.py and FLASK_DEBUG=1 to your
environment.sh.
* instead of using `python app.py runserver`, now you must run
`flask run -p 6012`. The -p command is important - the port must be
set before the config is loaded, so that it can live reload nicely.
(https://github.com/pallets/flask/issues/2113#issuecomment-268014481)
* find available commands by just running `flask`.
* run them using flask. eg `flask list_routes`
* define new tasks by giving them the decorator
`@app.cli.command('task-name')`. Task name isn't needed if it's just
the same as the function name. Alternatively, if app isn't available
in the current scope, you can invoke the decorator directly, as seen
in app/commands.py
`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
