darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2025-12-11 15:43:45 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
c89be0079a4c1bcd5c57caf31d59ae5e433f4f46
notifications-admin/app/notify_client/org_invite_api_client.py

48 lines
1.6 KiB
Python
Raw Normal View History

Enforce order and style of imports Done using isort[1], with the following command: ``` isort -rc ./app ./tests ``` Adds linting to the `run_tests.sh` script to stop badly-sorted imports getting re-introduced. Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because I think it gives the cleanest diffs, eg: ``` from third_party import ( lib1, lib2, lib3, lib4, ) ``` 1. https://pypi.python.org/pypi/isort
2018-02-20 11:22:17 +00:00
from app.notify_client import NotifyAdminAPIClient, _attach_current_user
invite-team-members
2018-02-19 16:53:29 +00:00
class OrgInviteApiClient(NotifyAdminAPIClient):
def init_app(self, app):
fix org invite api client
2018-03-07 18:09:33 +00:00
super().init_app(app)
invite-team-members
2018-02-19 16:53:29 +00:00
self.admin_url = app.config['ADMIN_BASE_URL']
def create_invite(self, invite_from_id, org_id, email_address):
data = {
'email_address': email_address,
'invited_by': invite_from_id,
'invite_link_host': self.admin_url,
}
data = _attach_current_user(data)
resp = self.post(url='/organisation/{}/invite'.format(org_id), data=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
return resp['data']
invite-team-members
2018-02-19 16:53:29 +00:00
def get_invites_for_organisation(self, org_id):
endpoint = '/organisation/{}/invite'.format(org_id)
resp = self.get(endpoint)
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
return resp['data']
invite-team-members
2018-02-19 16:53:29 +00:00
rename get_invited_user funcs make it clear they're expecting a service/org id
2021-03-05 17:04:35 +00:00
def get_invited_user_for_org(self, org_id, invited_org_user_id):
Add confirmation banner when cancelling user invites This shows the green banner with a tick when cancelling a user's invitation to a service or organisation. The accessibility audit noted that 'When cancelling an invite a new page loads, however, there is no immediate indication that the invite has been cancelled.' In order to display the invited user's email address as part of the flash message, this adds new methods to the api clients for invites to get a single invite.
2020-08-17 14:30:09 +01:00
return self.get(
f'/organisation/{org_id}/invite/{invited_org_user_id}'
)['data']
invite-team-members
2018-02-19 16:53:29 +00:00
def check_token(self, token):
Refactor the check token endpoint to use the newly merged api endpoints.
2018-02-26 11:50:40 +00:00
resp = self.get(url='/invite/organisation/{}'.format(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
return resp['data']
invite-team-members
2018-02-19 16:53:29 +00:00
def cancel_invited_user(self, org_id, invited_user_id):
data = {'status': 'cancelled'}
data = _attach_current_user(data)
self.post(url='/organisation/{0}/invite/{1}'.format(org_id, invited_user_id),
data=data)
def accept_invite(self, org_id, invited_user_id):
data = {'status': 'accepted'}
self.post(url='/organisation/{0}/invite/{1}'.format(org_id, invited_user_id),
data=data)
Initialise clients outside the app This avoids the annoying problem where you can’t import a client unless the app has already been initialised.
2018-10-26 15:39:32 +01:00
org_invite_api_client = OrgInviteApiClient()
Reference in New Issue Copy Permalink