For consistency with `.organisations`/`.organisation_ids`.
`.services` returns a list of semi-rich dictionaries for each service.
`.service_ids` returns service IDs only.
Users can only be archived by Platform Admin from the user page
(/users/<user_id>). This removes them from all services and orgs and
updates their details.
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
Two tests retained the old syntax because of mocker conflict:
when logging in as a user through client_request, it sets up a
side_effect on user_api_client.get_user to the user you log in
as. If you later want to set return_value for get_user to
something else, problems start :d.
- name
- email
- phone number
- services
- last login
- failed login attempts if any
The view can be accessed from results of find_users_by_email
logged_in_at added to User serialization on admin frontend as
a part of this work
