darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-06-05 22:10:44 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
17f74cf621ced95f044b4ee467441928b5b80e50
notifications-admin/tests/app/models/test_service.py

258 lines
8.6 KiB
Python
Raw Normal View History

Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
import uuid
Enforce service permissions This should catch typos more quickly and obviously.
2020-06-03 14:54:37 +01:00
import pytest
Fix unnecessary call to organisation API endpoint We’re caching the organisation name, but still talking to the API to see if the organisation exists. `Service().organisation_id` only goes to the JSON for the service. `Service().organisation` makes a separate API call. We only need the former to know if a service belongs to an organisation.
2020-04-02 15:06:03 +01:00
from app.models.organisation import Organisation
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
from app.models.service import 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 app.models.user import User
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
from tests import organisation_json
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
from tests.conftest import ORGANISATION_ID
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
INV_PARENT_FOLDER_ID = '7e979e79-d970-43a5-ac69-b625a8d147b0'
INV_CHILD_1_FOLDER_ID = '92ee1ee0-e4ee-4dcc-b1a7-a5da9ebcfa2b'
VIS_PARENT_FOLDER_ID = 'bbbb222b-2b22-2b22-222b-b222b22b2222'
INV_CHILD_2_FOLDER_ID = 'fafe723f-1d39-4a10-865f-e551e03d8886'
def _get_all_folders(active_user_with_permissions):
return [
{
'name': "Invisible folder",
'id': str(uuid.uuid4()),
'parent_id': None,
'users_with_permission': []
},
{
'name': "Parent 1 - invisible",
'id': INV_PARENT_FOLDER_ID,
'parent_id': None,
'users_with_permission': []
},
{
'name': "1's Visible child",
'id': str(uuid.uuid4()),
'parent_id': INV_PARENT_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "1's Invisible child",
'id': INV_CHILD_1_FOLDER_ID,
'parent_id': INV_PARENT_FOLDER_ID,
'users_with_permission': []
},
{
'name': "1's Visible grandchild",
'id': str(uuid.uuid4()),
'parent_id': INV_CHILD_1_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "Parent 2 - visible",
'id': VIS_PARENT_FOLDER_ID,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "2's Visible child",
'id': str(uuid.uuid4()),
'parent_id': VIS_PARENT_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "2's Invisible child",
'id': INV_CHILD_2_FOLDER_ID,
'parent_id': VIS_PARENT_FOLDER_ID,
'users_with_permission': []
},
{
'name': "2's Visible grandchild",
'id': str(uuid.uuid4()),
'parent_id': INV_CHILD_2_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
]
def test_get_user_template_folders_only_returns_folders_visible_to_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
app_,
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
mock_get_template_folders,
service_one,
active_user_with_permissions,
mocker
):
mock_get_template_folders.return_value = _get_all_folders(active_user_with_permissions)
service = Service(service_one)
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
result = service.get_user_template_folders(User(active_user_with_permissions))
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
assert result == [
{
Use chevrons not slashes to separate folders It looks weird to have two different visual treatments for showing a navigable hierarchy. I reckon losing the slash won’t make things less folder like – Windows for example uses chevrons as foler separators.
2019-06-24 16:02:49 +01:00
'name': ["Parent 1 - invisible", "1's Visible child"],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
'id': mocker.ANY,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
Use chevrons not slashes to separate folders It looks weird to have two different visual treatments for showing a navigable hierarchy. I reckon losing the slash won’t make things less folder like – Windows for example uses chevrons as foler separators.
2019-06-24 16:02:49 +01:00
'name': ["Parent 1 - invisible", ["1's Invisible child", "1's Visible grandchild"]],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
'id': mocker.ANY,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "2's Visible child",
'id': mocker.ANY,
'parent_id': VIS_PARENT_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
Use chevrons not slashes to separate folders It looks weird to have two different visual treatments for showing a navigable hierarchy. I reckon losing the slash won’t make things less folder like – Windows for example uses chevrons as foler separators.
2019-06-24 16:02:49 +01:00
'name': ["2's Invisible child", "2's Visible grandchild"],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
'id': mocker.ANY,
'parent_id': VIS_PARENT_FOLDER_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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "Parent 2 - visible",
'id': VIS_PARENT_FOLDER_ID,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
]
def test_get_template_folders_shows_user_folders_when_user_id_passed_in(
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
app_,
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
mock_get_template_folders,
service_one,
active_user_with_permissions,
mocker
):
mock_get_template_folders.return_value = _get_all_folders(active_user_with_permissions)
service = Service(service_one)
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
result = service.get_template_folders(user=User(active_user_with_permissions))
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
assert result == [
{
Use chevrons not slashes to separate folders It looks weird to have two different visual treatments for showing a navigable hierarchy. I reckon losing the slash won’t make things less folder like – Windows for example uses chevrons as foler separators.
2019-06-24 16:02:49 +01:00
'name': ["Parent 1 - invisible", "1's Visible child"],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
'id': mocker.ANY,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']]
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
Use chevrons not slashes to separate folders It looks weird to have two different visual treatments for showing a navigable hierarchy. I reckon losing the slash won’t make things less folder like – Windows for example uses chevrons as foler separators.
2019-06-24 16:02:49 +01:00
'name': ["Parent 1 - invisible", ["1's Invisible child", "1's Visible grandchild"]],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
'id': mocker.ANY,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']]
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
{
'name': "Parent 2 - visible",
'id': VIS_PARENT_FOLDER_ID,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']]
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
},
]
def test_get_template_folders_shows_all_folders_when_user_id_not_passed_in(
mock_get_template_folders,
service_one,
active_user_with_permissions,
mocker
):
mock_get_template_folders.return_value = _get_all_folders(active_user_with_permissions)
service = Service(service_one)
result = service.get_template_folders()
assert result == [
{
'name': "Invisible folder",
'id': mocker.ANY,
'parent_id': None,
'users_with_permission': []
},
{
'name': "Parent 1 - invisible",
'id': INV_PARENT_FOLDER_ID,
'parent_id': None,
'users_with_permission': []
},
{
'name': "Parent 2 - visible",
'id': VIS_PARENT_FOLDER_ID,
'parent_id': 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
'users_with_permission': [active_user_with_permissions['id']],
Test that folders are filtered based on user permission at service level
2019-03-01 17:50:36 +00:00
}
]
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
def test_organisation_type_when_services_organisation_has_no_org_type(mocker, service_one):
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
service = Service(service_one)
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
service._dict['organisation_id'] = ORGANISATION_ID
org = organisation_json(organisation_type=None)
mocker.patch('app.organisations_client.get_organisation', return_value=org)
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
assert not org['organisation_type']
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
assert service.organisation_type == 'central'
def test_organisation_type_when_service_and_its_org_both_have_an_org_type(mocker, service_one):
# service_one has an organisation_type of 'central'
service = Service(service_one)
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
service._dict['organisation'] = ORGANISATION_ID
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
org = organisation_json(organisation_type='local')
Cache organisation name in Redis A lot of pages in the admin app are now generated entirely from Redis, without touching the API. The one remaining API call that a lot of pages make, when the user is platform admin or a member of an organisation, is to get the name of the current service’s organisation. This commit adds some code to start caching that as well, which should speed up page load times for when we’re clicking around the admin app (it’s typically 100ms just to get the organisation, and more than that when the API is under load). This means changing the service model to get the organisation from the API by ID, not by service ID. Otherwise it would be very hard to clear the cache if the name of the organisation ever changed. We can’t cache the whole organisation because it has a `count_of_live_services` field which can change at any time, without an update being made.
2020-03-20 08:42:33 +00:00
mocker.patch('app.organisations_client.get_organisation', return_value=org)
Add organisation_type property to Service model This will return the organisation_type of the service's organisation (if there is one), or the organisation_type of the service if not.
2019-07-09 10:38:07 +01:00
assert service.organisation_type == 'local'
Fix unnecessary call to organisation API endpoint We’re caching the organisation name, but still talking to the API to see if the organisation exists. `Service().organisation_id` only goes to the JSON for the service. `Service().organisation` makes a separate API call. We only need the former to know if a service belongs to an organisation.
2020-04-02 15:06:03 +01:00
def test_organisation_name_comes_from_cache(mocker, service_one):
mock_redis_get = mocker.patch(
'app.extensions.RedisClient.get',
return_value=b'"Borchester Council"',
)
mock_get_organisation = mocker.patch('app.organisations_client.get_organisation')
service = Service(service_one)
service._dict['organisation'] = ORGANISATION_ID
assert service.organisation_name == 'Borchester Council'
mock_redis_get.assert_called_once_with(f'organisation-{ORGANISATION_ID}-name')
assert mock_get_organisation.called is False
def test_organisation_name_goes_into_cache(mocker, service_one):
mocker.patch(
'app.extensions.RedisClient.get',
return_value=None,
)
mock_redis_set = mocker.patch(
'app.extensions.RedisClient.set',
)
mocker.patch(
'app.organisations_client.get_organisation',
return_value=organisation_json(),
)
service = Service(service_one)
service._dict['organisation'] = ORGANISATION_ID
assert service.organisation_name == 'Test Organisation'
mock_redis_set.assert_called_once_with(
f'organisation-{ORGANISATION_ID}-name',
'"Test Organisation"',
ex=604800,
)
def test_service_without_organisation_doesnt_need_org_api(mocker, service_one):
mock_redis_get = mocker.patch('app.extensions.RedisClient.get')
mock_get_organisation = mocker.patch('app.organisations_client.get_organisation')
service = Service(service_one)
service._dict['organisation'] = None
assert service.organisation_id is None
assert service.organisation_name is None
assert isinstance(service.organisation, Organisation)
assert mock_redis_get.called is False
assert mock_get_organisation.called is False
Enforce service permissions This should catch typos more quickly and obviously.
2020-06-03 14:54:37 +01:00
def test_bad_permission_raises(service_one):
with pytest.raises(KeyError) as e:
Service(service_one).has_permission('foo')
assert str(e.value) == "'foo is not a service permission'"
Reference in New Issue Copy Permalink