2019-06-05 10:34:32 +01:00
|
|
|
from collections.abc import Sequence
|
2019-06-07 09:26:11 +01:00
|
|
|
from itertools import chain
|
2019-06-05 10:34:32 +01:00
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
from flask import abort, current_app, request, session
|
|
|
|
|
from flask_login import AnonymousUserMixin, UserMixin, login_user
|
|
|
|
|
from notifications_python_client.errors import HTTPError
|
2019-04-04 11:18:22 +01:00
|
|
|
from werkzeug.utils import cached_property
|
2018-09-20 09:43:28 +01:00
|
|
|
|
2019-05-28 11:42:32 +01:00
|
|
|
from app.models import JSONModel
|
2019-04-04 11:18:22 +01:00
|
|
|
from app.models.organisation import Organisation
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
from app.models.roles_and_permissions import (
|
|
|
|
|
all_permissions,
|
|
|
|
|
translate_permissions_from_db_to_admin_roles,
|
|
|
|
|
)
|
|
|
|
|
from app.notify_client import InviteTokenError
|
|
|
|
|
from app.notify_client.invite_api_client import invite_api_client
|
|
|
|
|
from app.notify_client.org_invite_api_client import org_invite_api_client
|
2019-04-04 11:18:22 +01:00
|
|
|
from app.notify_client.organisations_api_client import organisations_client
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
from app.notify_client.user_api_client import user_api_client
|
2018-12-12 12:29:08 +00:00
|
|
|
from app.utils import is_gov_user
|
|
|
|
|
|
2018-01-11 22:12:30 +00:00
|
|
|
|
2018-02-21 10:18:56 +00:00
|
|
|
def _get_service_id_from_view_args():
|
2019-05-03 09:59:02 +01:00
|
|
|
return str(request.view_args.get('service_id', '')) or None
|
2018-02-21 10:18:56 +00:00
|
|
|
|
|
|
|
|
|
2018-03-01 11:34:53 +00:00
|
|
|
def _get_org_id_from_view_args():
|
2019-05-03 09:59:02 +01:00
|
|
|
return str(request.view_args.get('org_id', '')) or None
|
2018-03-01 11:34:53 +00:00
|
|
|
|
|
|
|
|
|
2019-05-28 11:42:32 +01:00
|
|
|
class User(JSONModel, UserMixin):
|
|
|
|
|
|
|
|
|
|
ALLOWED_PROPERTIES = {
|
|
|
|
|
'id',
|
|
|
|
|
'name',
|
|
|
|
|
'email_address',
|
|
|
|
|
'auth_type',
|
2019-06-05 12:14:50 +01:00
|
|
|
'current_session_id',
|
2019-05-28 11:42:32 +01:00
|
|
|
'failed_login_count',
|
|
|
|
|
'logged_in_at',
|
2019-06-05 12:14:50 +01:00
|
|
|
'mobile_number',
|
|
|
|
|
'password_changed_at',
|
|
|
|
|
'permissions',
|
2019-05-28 11:42:32 +01:00
|
|
|
'platform_admin',
|
|
|
|
|
'services',
|
2019-06-05 12:14:50 +01:00
|
|
|
'state',
|
2019-05-28 11:42:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def __init__(self, _dict):
|
|
|
|
|
super().__init__(_dict)
|
2019-05-28 11:52:01 +01:00
|
|
|
self.permissions = _dict.get('permissions', {})
|
2019-05-28 11:42:32 +01:00
|
|
|
self.max_failed_login_count = current_app.config['MAX_FAILED_LOGIN_COUNT']
|
2016-03-01 10:45:13 +00:00
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@classmethod
|
|
|
|
|
def from_id(cls, user_id):
|
|
|
|
|
return cls(user_api_client.get_user(user_id))
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_email_address(cls, email_address):
|
|
|
|
|
return cls(user_api_client.get_user_by_email(email_address))
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_email_address_or_none(cls, email_address):
|
|
|
|
|
response = user_api_client.get_user_by_email_or_none(email_address)
|
|
|
|
|
if response:
|
|
|
|
|
return cls(response)
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def already_registered(email_address):
|
|
|
|
|
return bool(User.from_email_address_or_none(email_address))
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_email_address_and_password_or_none(cls, email_address, password):
|
|
|
|
|
user = cls.from_email_address_or_none(email_address)
|
|
|
|
|
if not user:
|
|
|
|
|
return None
|
|
|
|
|
if user.locked:
|
|
|
|
|
return None
|
|
|
|
|
if not user_api_client.verify_password(user.id, password):
|
|
|
|
|
return None
|
|
|
|
|
return user
|
|
|
|
|
|
2019-05-28 11:52:01 +01:00
|
|
|
@property
|
|
|
|
|
def permissions(self):
|
|
|
|
|
return self._permissions
|
|
|
|
|
|
|
|
|
|
@permissions.setter
|
|
|
|
|
def permissions(self, permissions_by_service):
|
2018-02-28 15:37:49 +00:00
|
|
|
"""
|
|
|
|
|
Permissions is a dict {'service_id': ['permission a', 'permission b', 'permission c']}
|
|
|
|
|
|
|
|
|
|
The api currently returns some granular permissions that we don't set or use separately (but may want
|
|
|
|
|
to in the future):
|
|
|
|
|
* send_texts, send_letters and send_emails become send_messages
|
|
|
|
|
* manage_user and manage_settings become
|
|
|
|
|
users either have all three permissions for a service or none of them, they're not helpful to distinguish
|
|
|
|
|
between on the front end. So lets collapse them into "send_messages" and "manage_service". If we want to split
|
|
|
|
|
them out later, we'll need to rework this function.
|
|
|
|
|
"""
|
|
|
|
|
self._permissions = {
|
|
|
|
|
service: translate_permissions_from_db_to_admin_roles(permissions)
|
|
|
|
|
for service, permissions
|
|
|
|
|
in permissions_by_service.items()
|
|
|
|
|
}
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
def update(self, **kwargs):
|
|
|
|
|
response = user_api_client.update_user_attribute(self.id, **kwargs)
|
|
|
|
|
self.__init__(response)
|
|
|
|
|
|
|
|
|
|
def update_password(self, password):
|
|
|
|
|
response = user_api_client.update_password(self.id, password)
|
|
|
|
|
self.__init__(response)
|
|
|
|
|
|
|
|
|
|
def set_permissions(self, service_id, permissions, folder_permissions):
|
|
|
|
|
user_api_client.set_user_permissions(
|
|
|
|
|
self.id,
|
|
|
|
|
service_id,
|
|
|
|
|
permissions=permissions,
|
|
|
|
|
folder_permissions=folder_permissions,
|
|
|
|
|
)
|
2016-03-01 10:45:13 +00:00
|
|
|
|
2017-02-17 14:06:09 +00:00
|
|
|
def logged_in_elsewhere(self):
|
2017-02-23 16:38:18 +00:00
|
|
|
# if the current user (ie: db object) has no session, they've never logged in before
|
|
|
|
|
return self.current_session_id is not None and session.get('current_session_id') != self.current_session_id
|
2017-02-17 14:06:09 +00:00
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
def activate(self):
|
|
|
|
|
if self.state == 'pending':
|
|
|
|
|
user_data = user_api_client.activate_user(self.id)
|
|
|
|
|
return self.__class__(user_data['data'])
|
|
|
|
|
else:
|
|
|
|
|
return self
|
|
|
|
|
|
|
|
|
|
def login(self):
|
|
|
|
|
login_user(self)
|
|
|
|
|
|
|
|
|
|
def sign_in(self):
|
|
|
|
|
|
|
|
|
|
session['user_details'] = {"email": self.email_address, "id": self.id}
|
|
|
|
|
|
|
|
|
|
if not self.is_active:
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
if self.email_auth:
|
|
|
|
|
user_api_client.send_verify_code(self.id, 'email', None, request.args.get('next'))
|
|
|
|
|
if self.sms_auth:
|
|
|
|
|
user_api_client.send_verify_code(self.id, 'sms', self.mobile_number)
|
|
|
|
|
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def sms_auth(self):
|
|
|
|
|
return self.auth_type == 'sms_auth'
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def email_auth(self):
|
|
|
|
|
return self.auth_type == 'email_auth'
|
|
|
|
|
|
|
|
|
|
def reset_failed_login_count(self):
|
|
|
|
|
user_api_client.reset_failed_login_count(self.id)
|
|
|
|
|
|
2016-05-04 13:01:55 +01:00
|
|
|
@property
|
2016-03-01 10:45:13 +00:00
|
|
|
def is_active(self):
|
|
|
|
|
return self.state == 'active'
|
|
|
|
|
|
2018-12-12 12:29:08 +00:00
|
|
|
@property
|
|
|
|
|
def is_gov_user(self):
|
|
|
|
|
return is_gov_user(self.email_address)
|
|
|
|
|
|
2016-05-04 13:01:55 +01:00
|
|
|
@property
|
2016-03-01 10:45:13 +00:00
|
|
|
def is_authenticated(self):
|
2017-02-17 14:06:09 +00:00
|
|
|
return (
|
|
|
|
|
not self.logged_in_elsewhere() and
|
|
|
|
|
super(User, self).is_authenticated
|
|
|
|
|
)
|
2016-03-01 10:45:13 +00:00
|
|
|
|
2018-03-01 10:37:55 +00:00
|
|
|
def has_permissions(self, *permissions, restrict_admin_usage=False):
|
2018-01-11 22:36:13 +00:00
|
|
|
unknown_permissions = set(permissions) - all_permissions
|
|
|
|
|
if unknown_permissions:
|
2018-02-28 15:37:49 +00:00
|
|
|
raise TypeError('{} are not valid permissions'.format(list(unknown_permissions)))
|
2018-01-11 22:36:13 +00:00
|
|
|
|
2016-03-18 16:20:37 +00:00
|
|
|
# Service id is always set on the request for service specific views.
|
2018-02-21 10:18:56 +00:00
|
|
|
service_id = _get_service_id_from_view_args()
|
2018-03-01 11:34:53 +00:00
|
|
|
org_id = _get_org_id_from_view_args()
|
|
|
|
|
|
2018-03-01 12:08:22 +00:00
|
|
|
if not service_id and not org_id:
|
|
|
|
|
# we shouldn't have any pages that require permissions, but don't specify a service or organisation.
|
|
|
|
|
# use @user_is_platform_admin for platform admin only pages
|
|
|
|
|
raise NotImplementedError
|
|
|
|
|
|
|
|
|
|
# platform admins should be able to do most things (except eg send messages, or create api keys)
|
|
|
|
|
if self.platform_admin and not restrict_admin_usage:
|
|
|
|
|
return True
|
|
|
|
|
|
2018-03-01 11:34:53 +00:00
|
|
|
if org_id:
|
2019-06-07 09:26:11 +01:00
|
|
|
return org_id in self.organisation_ids
|
2018-08-06 11:09:57 +01:00
|
|
|
if not permissions:
|
2018-11-19 15:26:43 +00:00
|
|
|
return service_id in self.services
|
2018-08-06 11:09:57 +01:00
|
|
|
if service_id:
|
2018-03-01 11:34:53 +00:00
|
|
|
return any(x in self._permissions.get(service_id, []) for x in permissions)
|
2016-03-01 10:45:13 +00:00
|
|
|
|
2018-02-28 18:13:29 +00:00
|
|
|
def has_permission_for_service(self, service_id, permission):
|
|
|
|
|
return permission in self._permissions.get(service_id, [])
|
|
|
|
|
|
2019-03-29 16:44:57 +00:00
|
|
|
def has_template_folder_permission(self, template_folder, service=None):
|
2019-03-11 14:13:56 +00:00
|
|
|
if self.platform_admin:
|
|
|
|
|
return True
|
|
|
|
|
|
2019-03-19 15:58:18 +00:00
|
|
|
# Top-level templates are always visible
|
2019-03-28 16:07:52 +00:00
|
|
|
if template_folder is None or template_folder['id'] is None:
|
2019-03-19 15:58:18 +00:00
|
|
|
return True
|
|
|
|
|
|
2019-03-11 14:13:56 +00:00
|
|
|
return self.id in template_folder.get("users_with_permission", [])
|
|
|
|
|
|
2019-04-04 17:55:37 +01:00
|
|
|
def template_folders_for_service(self, service=None):
|
|
|
|
|
"""
|
|
|
|
|
Returns list of template folders that a user can view for a given service
|
|
|
|
|
"""
|
|
|
|
|
return [
|
|
|
|
|
template_folder
|
|
|
|
|
for template_folder in service.all_template_folders
|
|
|
|
|
if self.id in template_folder.get("users_with_permission", [])
|
|
|
|
|
]
|
|
|
|
|
|
2019-01-15 17:31:55 +00:00
|
|
|
def belongs_to_service(self, service_id):
|
|
|
|
|
return str(service_id) in self.services
|
|
|
|
|
|
2019-01-07 14:49:33 +00:00
|
|
|
def belongs_to_service_or_403(self, service_id):
|
2019-01-15 17:31:55 +00:00
|
|
|
if not self.belongs_to_service(service_id):
|
2019-01-07 14:49:33 +00:00
|
|
|
abort(403)
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@property
|
|
|
|
|
def locked(self):
|
2016-03-01 10:45:13 +00:00
|
|
|
return self.failed_login_count >= self.max_failed_login_count
|
|
|
|
|
|
2019-04-04 11:18:22 +01:00
|
|
|
@property
|
|
|
|
|
def email_domain(self):
|
|
|
|
|
return self.email_address.split('@')[-1]
|
|
|
|
|
|
2019-06-07 09:07:11 +01:00
|
|
|
@cached_property
|
2019-06-07 09:26:11 +01:00
|
|
|
def orgs_and_services(self):
|
|
|
|
|
return user_api_client.get_organisations_and_services_for_user(self.id)
|
|
|
|
|
|
|
|
|
|
@property
|
2019-06-07 09:07:11 +01:00
|
|
|
def all_services(self):
|
2019-06-07 09:26:11 +01:00
|
|
|
all_services = self.orgs_and_services['services_without_organisations'] + next(chain(
|
|
|
|
|
org['services'] for org in self.orgs_and_services['organisations']
|
|
|
|
|
), [])
|
|
|
|
|
return sorted(all_services, key=lambda service: service['name'].lower())
|
2019-06-07 09:07:11 +01:00
|
|
|
|
2019-06-07 09:14:14 +01:00
|
|
|
@property
|
|
|
|
|
def all_service_ids(self):
|
|
|
|
|
return {
|
|
|
|
|
service['id'] for service in self.all_services
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-07 09:07:11 +01:00
|
|
|
@property
|
|
|
|
|
def trial_mode_services(self):
|
|
|
|
|
return [
|
|
|
|
|
service for service in self.all_services
|
|
|
|
|
if service['restricted']
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def live_services(self):
|
|
|
|
|
return [
|
|
|
|
|
service for service in self.all_services
|
|
|
|
|
if not service['restricted']
|
|
|
|
|
]
|
|
|
|
|
|
2019-06-07 09:26:11 +01:00
|
|
|
@property
|
|
|
|
|
def organisations(self):
|
2019-06-07 09:58:09 +01:00
|
|
|
return [
|
|
|
|
|
Organisation.from_id(organisation['id'])
|
|
|
|
|
for organisation in self.orgs_and_services['organisations']
|
|
|
|
|
]
|
2019-06-07 09:26:11 +01:00
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def organisation_ids(self):
|
|
|
|
|
return self._dict['organisations']
|
|
|
|
|
|
2019-04-04 11:18:22 +01:00
|
|
|
@cached_property
|
|
|
|
|
def default_organisation(self):
|
|
|
|
|
return Organisation(
|
|
|
|
|
organisations_client.get_organisation_by_domain(self.email_domain)
|
|
|
|
|
)
|
|
|
|
|
|
2019-05-07 10:31:16 +01:00
|
|
|
@property
|
|
|
|
|
def default_organisation_type(self):
|
|
|
|
|
if self.default_organisation:
|
|
|
|
|
return self.default_organisation.organisation_type
|
|
|
|
|
if self.has_nhs_email_address:
|
|
|
|
|
return 'nhs'
|
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def has_nhs_email_address(self):
|
|
|
|
|
return self.email_address.lower().endswith((
|
|
|
|
|
'@nhs.uk', '.nhs.uk', '@nhs.net', '.nhs.net',
|
|
|
|
|
))
|
|
|
|
|
|
2016-03-01 10:45:13 +00:00
|
|
|
def serialize(self):
|
2017-02-17 14:06:09 +00:00
|
|
|
dct = {
|
|
|
|
|
"id": self.id,
|
|
|
|
|
"name": self.name,
|
|
|
|
|
"email_address": self.email_address,
|
|
|
|
|
"mobile_number": self.mobile_number,
|
|
|
|
|
"password_changed_at": self.password_changed_at,
|
|
|
|
|
"state": self.state,
|
|
|
|
|
"failed_login_count": self.failed_login_count,
|
|
|
|
|
"permissions": [x for x in self._permissions],
|
2019-06-07 09:26:11 +01:00
|
|
|
"organisations": self.organisation_ids,
|
2017-02-17 14:06:09 +00:00
|
|
|
"current_session_id": self.current_session_id
|
|
|
|
|
}
|
|
|
|
|
if hasattr(self, '_password'):
|
2016-03-01 10:45:13 +00:00
|
|
|
dct['password'] = self._password
|
|
|
|
|
return dct
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@classmethod
|
|
|
|
|
def register(
|
|
|
|
|
cls,
|
|
|
|
|
name,
|
|
|
|
|
email_address,
|
|
|
|
|
mobile_number,
|
|
|
|
|
password,
|
|
|
|
|
auth_type,
|
|
|
|
|
):
|
|
|
|
|
return cls(user_api_client.register_user(
|
|
|
|
|
name,
|
|
|
|
|
email_address,
|
|
|
|
|
mobile_number or None,
|
|
|
|
|
password,
|
|
|
|
|
auth_type,
|
|
|
|
|
))
|
|
|
|
|
|
2016-03-01 10:45:13 +00:00
|
|
|
def set_password(self, pwd):
|
|
|
|
|
self._password = pwd
|
2016-02-29 17:35:21 +00:00
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
def send_verify_email(self):
|
|
|
|
|
user_api_client.send_verify_email(self.id, self.email_address)
|
|
|
|
|
|
|
|
|
|
def send_verify_code(self, to=None):
|
|
|
|
|
user_api_client.send_verify_code(self.id, 'sms', to or self.mobile_number)
|
|
|
|
|
|
|
|
|
|
def send_already_registered_email(self):
|
|
|
|
|
user_api_client.send_already_registered_email(self.id, self.email_address)
|
|
|
|
|
|
|
|
|
|
def refresh_session_id(self):
|
|
|
|
|
self.current_session_id = user_api_client.get_user(self.id).get('current_session_id')
|
|
|
|
|
session['current_session_id'] = self.current_session_id
|
|
|
|
|
|
2016-02-29 17:35:21 +00:00
|
|
|
|
2019-06-05 10:47:55 +01:00
|
|
|
class InvitedUser(JSONModel):
|
|
|
|
|
|
|
|
|
|
ALLOWED_PROPERTIES = {
|
|
|
|
|
'id',
|
|
|
|
|
'service',
|
|
|
|
|
'email_address',
|
|
|
|
|
'permissions',
|
|
|
|
|
'status',
|
|
|
|
|
'created_at',
|
|
|
|
|
'auth_type',
|
|
|
|
|
'folder_permissions',
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def __init__(self, _dict):
|
|
|
|
|
super().__init__(_dict)
|
|
|
|
|
self.permissions = _dict.get('permissions') or []
|
|
|
|
|
self._from_user = _dict['from_user']
|
2016-02-29 17:35:21 +00:00
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@classmethod
|
|
|
|
|
def create(
|
|
|
|
|
cls,
|
|
|
|
|
invite_from_id,
|
|
|
|
|
service_id,
|
|
|
|
|
email_address,
|
|
|
|
|
permissions,
|
|
|
|
|
auth_type,
|
|
|
|
|
folder_permissions,
|
|
|
|
|
):
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(invite_api_client.create_invite(
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
invite_from_id,
|
|
|
|
|
service_id,
|
|
|
|
|
email_address,
|
|
|
|
|
permissions,
|
|
|
|
|
auth_type,
|
|
|
|
|
folder_permissions,
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
def accept_invite(self):
|
|
|
|
|
invite_api_client.accept_invite(self.service, self.id)
|
|
|
|
|
|
2019-06-06 17:24:48 +01:00
|
|
|
def add_to_service(self, existing_user_id):
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
user_api_client.add_user_to_service(
|
|
|
|
|
self.service,
|
2019-06-06 17:24:48 +01:00
|
|
|
existing_user_id,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
self.permissions,
|
|
|
|
|
self.folder_permissions,
|
|
|
|
|
)
|
|
|
|
|
|
2019-06-05 10:47:55 +01:00
|
|
|
@property
|
|
|
|
|
def permissions(self):
|
|
|
|
|
return self._permissions
|
|
|
|
|
|
|
|
|
|
@permissions.setter
|
|
|
|
|
def permissions(self, permissions):
|
|
|
|
|
if isinstance(permissions, list):
|
|
|
|
|
self._permissions = permissions
|
|
|
|
|
else:
|
|
|
|
|
self._permissions = permissions.split(',')
|
|
|
|
|
self._permissions = translate_permissions_from_db_to_admin_roles(self.permissions)
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@property
|
|
|
|
|
def from_user(self):
|
|
|
|
|
return User.from_id(self._from_user)
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def sms_auth(self):
|
|
|
|
|
return self.auth_type == 'sms_auth'
|
|
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def email_auth(self):
|
|
|
|
|
return self.auth_type == 'email_auth'
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_token(cls, token):
|
|
|
|
|
try:
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(invite_api_client.check_token(token))
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
except HTTPError as exception:
|
|
|
|
|
if exception.status_code == 400 and 'invitation' in exception.message:
|
|
|
|
|
raise InviteTokenError(exception.message['invitation'])
|
|
|
|
|
else:
|
|
|
|
|
raise exception
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_session(cls):
|
|
|
|
|
invited_user = session.get('invited_user')
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(invited_user) if invited_user else None
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
2017-10-15 15:02:01 +01:00
|
|
|
def has_permissions(self, *permissions):
|
2018-01-26 17:14:00 +00:00
|
|
|
if self.status == 'cancelled':
|
|
|
|
|
return False
|
2016-03-03 13:00:12 +00:00
|
|
|
return set(self.permissions) > set(permissions)
|
2016-03-02 15:25:04 +00:00
|
|
|
|
2018-02-28 18:13:29 +00:00
|
|
|
def has_permission_for_service(self, service_id, permission):
|
2018-08-06 11:10:37 +01:00
|
|
|
if self.status == 'cancelled':
|
2018-06-12 14:29:47 +01:00
|
|
|
return False
|
|
|
|
|
return self.service == service_id and permission in self.permissions
|
2018-02-28 18:13:29 +00:00
|
|
|
|
2016-03-03 15:26:18 +00:00
|
|
|
def __eq__(self, other):
|
|
|
|
|
return ((self.id,
|
|
|
|
|
self.service,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
self._from_user,
|
2016-03-03 15:26:18 +00:00
|
|
|
self.email_address,
|
2017-11-01 15:36:27 +00:00
|
|
|
self.auth_type,
|
2016-03-03 15:26:18 +00:00
|
|
|
self.status) == (other.id,
|
|
|
|
|
other.service,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
other._from_user,
|
2016-03-03 15:26:18 +00:00
|
|
|
other.email_address,
|
2017-11-01 15:36:27 +00:00
|
|
|
other.auth_type,
|
2016-03-03 15:26:18 +00:00
|
|
|
other.status))
|
|
|
|
|
|
|
|
|
|
def serialize(self, permissions_as_string=False):
|
|
|
|
|
data = {'id': self.id,
|
2016-03-02 15:25:04 +00:00
|
|
|
'service': self.service,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
'from_user': self._from_user,
|
2016-03-02 15:25:04 +00:00
|
|
|
'email_address': self.email_address,
|
2016-03-03 15:26:18 +00:00
|
|
|
'status': self.status,
|
2017-11-01 15:36:27 +00:00
|
|
|
'created_at': str(self.created_at),
|
2019-03-15 10:25:00 +00:00
|
|
|
'auth_type': self.auth_type,
|
|
|
|
|
'folder_permissions': self.folder_permissions
|
2016-03-02 15:25:04 +00:00
|
|
|
}
|
2016-03-03 15:26:18 +00:00
|
|
|
if permissions_as_string:
|
|
|
|
|
data['permissions'] = ','.join(self.permissions)
|
|
|
|
|
else:
|
2018-03-01 16:59:01 +00:00
|
|
|
data['permissions'] = sorted(self.permissions)
|
2016-03-03 15:26:18 +00:00
|
|
|
return data
|
2017-02-17 14:06:09 +00:00
|
|
|
|
2019-04-04 17:55:37 +01:00
|
|
|
def template_folders_for_service(self, service=None):
|
|
|
|
|
# only used on the manage users page to display the count, so okay to not be fully fledged for now
|
|
|
|
|
return [{'id': x} for x in self.folder_permissions]
|
|
|
|
|
|
2017-02-17 14:06:09 +00:00
|
|
|
|
2019-06-05 10:47:55 +01:00
|
|
|
class InvitedOrgUser(JSONModel):
|
2018-02-19 16:53:29 +00:00
|
|
|
|
2019-06-05 10:47:55 +01:00
|
|
|
ALLOWED_PROPERTIES = {
|
|
|
|
|
'id',
|
|
|
|
|
'organisation',
|
|
|
|
|
'email_address',
|
|
|
|
|
'status',
|
|
|
|
|
'created_at',
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def __init__(self, _dict):
|
|
|
|
|
super().__init__(_dict)
|
|
|
|
|
self._invited_by = _dict['invited_by']
|
2018-02-19 16:53:29 +00:00
|
|
|
|
|
|
|
|
def __eq__(self, other):
|
|
|
|
|
return ((self.id,
|
|
|
|
|
self.organisation,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
self._invited_by,
|
2018-02-19 16:53:29 +00:00
|
|
|
self.email_address,
|
|
|
|
|
self.status) == (other.id,
|
|
|
|
|
other.organisation,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
other._invited_by,
|
2018-02-19 16:53:29 +00:00
|
|
|
other.email_address,
|
|
|
|
|
other.status))
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@classmethod
|
|
|
|
|
def create(cls, invite_from_id, org_id, email_address):
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(org_invite_api_client.create_invite(
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
invite_from_id, org_id, email_address
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_session(cls):
|
|
|
|
|
invited_org_user = session.get('invited_org_user')
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(invited_org_user) if invited_org_user else None
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
2018-02-19 16:53:29 +00:00
|
|
|
def serialize(self, permissions_as_string=False):
|
|
|
|
|
data = {'id': self.id,
|
|
|
|
|
'organisation': self.organisation,
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
'invited_by': self._invited_by,
|
2018-02-19 16:53:29 +00:00
|
|
|
'email_address': self.email_address,
|
|
|
|
|
'status': self.status,
|
|
|
|
|
'created_at': str(self.created_at)
|
|
|
|
|
}
|
|
|
|
|
return data
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
@property
|
|
|
|
|
def invited_by(self):
|
|
|
|
|
return User.from_id(self._invited_by)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def from_token(cls, token):
|
|
|
|
|
try:
|
2019-06-05 10:47:55 +01:00
|
|
|
return cls(org_invite_api_client.check_token(token))
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
except HTTPError as exception:
|
|
|
|
|
if exception.status_code == 400 and 'invitation' in exception.message:
|
|
|
|
|
raise InviteTokenError(exception.message['invitation'])
|
|
|
|
|
else:
|
|
|
|
|
raise exception
|
|
|
|
|
|
|
|
|
|
def accept_invite(self):
|
|
|
|
|
org_invite_api_client.accept_invite(self.organisation, self.id)
|
|
|
|
|
|
|
|
|
|
def add_to_organisation(self):
|
|
|
|
|
user_api_client.add_user_to_organisation(self.organisation, self.id)
|
|
|
|
|
|
2018-02-19 16:53:29 +00:00
|
|
|
|
2017-02-17 14:06:09 +00:00
|
|
|
class AnonymousUser(AnonymousUserMixin):
|
|
|
|
|
# set the anonymous user so that if a new browser hits us we don't error http://stackoverflow.com/a/19275188
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
2017-02-17 14:06:09 +00:00
|
|
|
def logged_in_elsewhere(self):
|
|
|
|
|
return False
|
2019-04-04 11:18:22 +01:00
|
|
|
|
|
|
|
|
@property
|
|
|
|
|
def default_organisation(self):
|
|
|
|
|
return Organisation(None)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
|
2019-06-05 10:34:32 +01:00
|
|
|
class Users(Sequence):
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
client = user_api_client.get_users_for_service
|
2019-06-05 14:54:48 +01:00
|
|
|
model = User
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
def __init__(self, service_id):
|
|
|
|
|
self.users = self.client(service_id)
|
|
|
|
|
|
2019-06-05 10:34:32 +01:00
|
|
|
def __getitem__(self, index):
|
2019-06-05 14:54:48 +01:00
|
|
|
return self.model(self.users[index])
|
2019-06-05 10:34:32 +01:00
|
|
|
|
|
|
|
|
def __len__(self):
|
|
|
|
|
return len(self.users)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
def __add__(self, other):
|
|
|
|
|
return list(self) + list(other)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class OrganisationUsers(Users):
|
|
|
|
|
client = user_api_client.get_users_for_organisation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class InvitedUsers(Users):
|
|
|
|
|
|
|
|
|
|
client = invite_api_client.get_invites_for_service
|
|
|
|
|
model = InvitedUser
|
|
|
|
|
|
2019-06-05 10:34:32 +01:00
|
|
|
def __init__(self, service_id):
|
|
|
|
|
self.users = [
|
|
|
|
|
user for user in self.client(service_id)
|
|
|
|
|
if user['status'] != 'accepted'
|
|
|
|
|
]
|
|
|
|
|
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
|
|
|
|
|
class OrganisationInvitedUsers(InvitedUsers):
|
|
|
|
|
client = org_invite_api_client.get_invites_for_organisation
|
|
|
|
|
model = InvitedOrgUser
|