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
If you’ve spelt ‘postcode’ wrong, or missed only ‘address_line_2’ then
it’s pretty noisy to be told that your file needs columns called address
line 1, address line 2, and postcode.
It’s better to be specific about which column you need to fix in order
to get past this error. As a principle, we’ve found it better to tell
get people to fix one error at a time, rather than overwhelm them with a
list of errors to correct – this is why we split the recipient column
errors out separately in the first place.
Numbers over a billion overflow the two column layout. Numbers over one
hundred thousand overflow the three column layout.
This commit makes the type size smaller in these cases, so that the
numbers still fit in the boxes.
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.
We're now running our app as a wsgi app locally, so don't need to
distinguish between the two processes by having wsgi and application.py
whitenoise just serves static files nicely - we don't lose anything
by doing that locally.
