darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-11 09:28:27 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
a5ec03302e7799db4e330559b6cdaba7f5fba8d4
notifications-admin/tests/app/main/views/test_accept_invite.py

911 lines
26 KiB
Python
Raw Normal View History

Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
from unittest.mock import ANY, Mock, call
[WIP] Post does not need any data Invites rest module can use invited user object instead of dict.
2016-03-01 17:23:23 +00:00
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
import pytest
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 flask import url_for
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
from freezegun import freeze_time
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
from notifications_python_client.errors import HTTPError
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
Add cancelled-invite html. If a invited user accepts a cancelled invitation they are directed to a page telling them the invitation is cancelled. Without this they were able to register and were added to the service.
2016-03-04 14:42:52 +00:00
import app
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
from tests import service_json
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
from tests.conftest import (
SERVICE_ONE_ID,
Reduce the errors related to user fixtures We were using user fixtures in a lot of parameterized tests, but this is no longer allowed in Pytest 5. To avoid having to split up the parametrized tests (which would make the test files a lot longer and slightly more difficult to read) this commit creates functions which return various types of user json so that we can use these as the test parameters instead.
2019-12-19 16:59:07 +00:00
create_active_caseworking_user,
create_active_user_with_permissions,
Make a few more test files Pytest 5 compliant
2019-12-19 11:19:28 +00:00
normalize_spaces,
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
)
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
[WIP] Start of user accepting invite. This commit only deals with acceptance by users who are already in system. Changed invite client to return invited user objects instead of dictionaries. Added commented out test. fixed up fixtures to return invited user object for invites
2016-02-29 17:35:21 +00:00
Refactor accept invite test to avoid override This replaces the original fixture with a more explicit one, noting that none of the tests rely on this fixture as part of testing the scenarios when a user is already a member of the service.
2021-05-25 16:54:37 +01:00
@pytest.fixture()
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
def _mock_no_users_for_service(mocker):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch("app.models.user.Users.client_method", return_value=[])
Refactor accept invite test to avoid override This replaces the original fixture with a more explicit one, noting that none of the tests rely on this fixture as part of testing the scenarios when a user is already a member of the service.
2021-05-25 16:54:37 +01:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.fixture()
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
def mock_get_existing_user_by_email(mocker, api_user_active):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
return mocker.patch(
"app.user_api_client.get_user_by_email", return_value=api_user_active
)
Localise fixture to the only test that uses it
2021-05-25 17:00:45 +01:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.fixture()
Localise and simplify fixture to invite tests This isn't used anywhere else.
2021-05-25 17:55:52 +01:00
def mock_check_invite_token(mocker, sample_invite):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
return mocker.patch("app.invite_api_client.check_token", return_value=sample_invite)
Localise and simplify fixture to invite tests This isn't used anywhere else.
2021-05-25 17:55:52 +01:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_existing_user_accept_invite_calls_api_and_redirects_to_dashboard(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
service_one,
api_user_active,
mock_check_invite_token,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
mock_get_existing_user_by_email,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_accept_invite,
mock_add_user_to_service,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
mock_get_service,
make sure invite tokens still check token on admin for error handler to kick in
2017-11-01 16:02:05 +00:00
mocker,
Add audit event for inviting users to a service
2021-03-05 12:19:36 +00:00
mock_events,
mock_get_user,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_service = service_one["id"]
expected_permissions = {
"view_activity",
"send_messages",
"manage_service",
"manage_api_keys",
}
[WIP] Start of user accepting invite. This commit only deals with acceptance by users who are already in system. Changed invite client to return invited user objects instead of dictionaries. Added commented out test. fixed up fixtures to return invited user object for invites
2016-02-29 17:35:21 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
_expected_redirect=url_for(
"main.service_dashboard", service_id=expected_service
),
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
)
[WIP] Start of user accepting invite. This commit only deals with acceptance by users who are already in system. Changed invite client to return invited user objects instead of dictionaries. Added commented out test. fixed up fixtures to return invited user object for invites
2016-02-29 17:35:21 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_check_invite_token.assert_called_with("thisisnotarealtoken")
mock_get_existing_user_by_email.assert_called_with("invited_user@test.gsa.gov")
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_accept_invite.call_count == 1
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
mock_add_user_to_service.assert_called_with(
expected_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
api_user_active["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
expected_permissions,
[],
)
[WIP] Start of user accepting invite. This commit only deals with acceptance by users who are already in system. Changed invite client to return invited user objects instead of dictionaries. Added commented out test. fixed up fixtures to return invited user object for invites
2016-02-29 17:35:21 +00:00
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Set folder permissions when creating and accepting invites to services Added a folder permissions form to the page to invite users to services. This only shows if the service has 'edit_folder_permissions' enabled, and all folder checkboxes are checked by default. This change means that InviteApiClient.create_invite now sends folder_permissions through to notifications_api (so invites get created with folder permissions). Started passing the folder_permissions through to notifications-api when accepting an invite. This changes UserApiClient.add_user_to_service to send folder_permissions to notifications_api so that new users get folder permissions when they are added to the service.
2019-03-15 14:57:39 +00:00
def test_existing_user_with_no_permissions_or_folder_permissions_accept_invite(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mocker,
service_one,
api_user_active,
sample_invite,
mock_check_invite_token,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
mock_get_existing_user_by_email,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_add_user_to_service,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
mock_get_service,
Add audit event for inviting users to a service
2021-03-05 12:19:36 +00:00
mock_events,
mock_get_user,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_service = service_one["id"]
sample_invite["permissions"] = ""
ensure invited user permissions show up correctly
2018-03-01 16:59:01 +00:00
expected_permissions = set()
Set folder permissions when creating and accepting invites to services Added a folder permissions form to the page to invite users to services. This only shows if the service has 'edit_folder_permissions' enabled, and all folder checkboxes are checked by default. This change means that InviteApiClient.create_invite now sends folder_permissions through to notifications_api (so invites get created with folder permissions). Started passing the folder_permissions through to notifications-api when accepting an invite. This changes UserApiClient.add_user_to_service to send folder_permissions to notifications_api so that new users get folder permissions when they are added to the service.
2019-03-15 14:57:39 +00:00
expected_folder_permissions = []
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch("app.invite_api_client.accept_invite", return_value=sample_invite)
Bug fix for passing list of empty string if no permissions selected for invite. Send empty list instead.
2016-03-11 12:50:25 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_expected_status=302,
)
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_add_user_to_service.assert_called_with(
expected_service,
api_user_active["id"],
expected_permissions,
expected_folder_permissions,
)
Bug fix for passing list of empty string if no permissions selected for invite. Send empty list instead.
2016-03-11 12:50:25 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_if_existing_user_accepts_twice_they_redirect_to_sign_in(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mocker,
sample_invite,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_get_service,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
# Logging out updates the current session ID to `None`
mock_update_user_attribute.reset_mock()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["status"] = "accepted"
Check user invite status not accepted before proceeding with flow.
2016-03-10 11:57:40 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=True,
)
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
assert (
page.h1.string,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
page.select("main p")[0].text.strip(),
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
) == (
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"You need to sign in again",
"We signed you out because you have not used Notify for a while.",
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
# We don’t let people update `email_access_validated_at` using an
# already-accepted invite
assert mock_update_user_attribute.called is False
Check user invite status not accepted before proceeding with flow.
2016-03-10 11:57:40 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
def test_invite_goes_in_session(
client_request,
mocker,
sample_invite,
mock_get_service,
api_user_active,
mock_check_invite_token,
mock_get_user_by_email,
mock_add_user_to_service,
mock_accept_invite,
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = "test@user.gsa.gov"
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
_expected_status=302,
_expected_redirect=url_for(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.service_dashboard",
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
service_id=SERVICE_ONE_ID,
),
_follow_redirects=False,
)
with client_request.session_transaction() as session:
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert session["invited_user_id"] == sample_invite["id"]
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@pytest.mark.parametrize(
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
("user", "landing_page_title"),
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
[
(create_active_user_with_permissions(), "Dashboard"),
(create_active_caseworking_user(), "Templates"),
],
)
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
def test_accepting_invite_removes_invite_from_session(
client_request,
mocker,
sample_invite,
mock_get_service,
service_one,
mock_check_invite_token,
mock_get_user_by_email,
mock_add_user_to_service,
mock_accept_invite,
mock_get_service_templates,
mock_get_template_statistics,
Use new API endpoint for scheduled job stats Depends on: - [ ] https://github.com/alphagov/notifications-api/pull/2984
2020-09-28 14:28:23 +01:00
mock_has_no_jobs,
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
mock_get_service_statistics,
show list of template folders on the choose templates page Not linking anywhere yet. Also not sorted, and not filtered by parent_id.
2018-11-01 17:11:58 +00:00
mock_get_template_folders,
Rename billing API methods to be recognisable I struggled to distinguish which was which as neither mentioned if the data they returned was monthly or annual.
2022-04-29 16:25:58 +01:00
mock_get_annual_usage_for_service,
mock_get_monthly_usage_for_service,
Put usage summary back on the dashboard This reverts 1b1839ad301725c179a2f5b5d1fe43b66ea41e50, which removed the usage from the dashboard because it was causing performance problems: > **The yearly usage section on the dashboard page takes too log as a > result services with large yearly stats are timing out.** > > As a short term fix we have taken the yearly stats off the dashboard. > > There is a plan to create permanent statistic tables to warehouse the > data. The long term fix (the fact tables) is now in place, so it should be OK to bring this back. This is part of a wider piece of work to refresh the dashboard page now that jobs are moving to their own page.
2019-10-25 13:27:46 +01:00
mock_get_free_sms_fragment_limit,
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
mock_get_inbound_sms_summary,
Allow users of the API to search templates by ID For someone who has retrieved a template ID from their system the only way to find it in Notify is: - hack the URL - click through every template, visually inspecting the ID shown on the page until you find the right one Neither of these is ideal. This commit adds searching by ID, for those services who have an API integration. This means we don’t need to confuse teams who aren’t using the API by talking about IDs. This is similar to how we let these teams search for notifications by reference[1] 1. https://github.com/alphagov/notifications-admin/pull/3223/files
2021-04-13 13:59:51 +01:00
mock_get_api_keys,
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
fake_uuid,
user,
landing_page_title,
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = user["email_address"]
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
client_request.login(user)
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
_follow_redirects=True,
)
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert normalize_spaces(page.select_one("h1").text) == landing_page_title
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
with client_request.session_transaction() as session:
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert "invited_user_id" not in session
Make sure caseworking users clear their invite There was a bug where caseworking users skipped the part of the invite flow where their invite was cleared from the session. This caused a 500 if they later tried to create another service. This commit makes sure that both types of user have the invite cleared from the session after accepting it.
2018-07-05 11:45:09 +01:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12T12:12:12")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_existing_user_of_service_get_redirected_to_signin(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mocker,
api_user_active,
sample_invite,
mock_get_service,
mock_get_user_by_email,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_accept_invite,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = api_user_active["email_address"]
mocker.patch("app.models.user.Users.client_method", return_value=[api_user_active])
Additional check needed to see if user was already a user for the service that they were invited to.
2016-03-15 15:32:30 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=True,
)
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
assert (
page.h1.string,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
page.select("main p")[0].text.strip(),
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
) == (
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"You need to sign in again",
"We signed you out because you have not used Notify for a while.",
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_accept_invite.call_count == 1
Additional check needed to see if user was already a user for the service that they were invited to.
2016-03-15 15:32:30 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
def test_accept_invite_redirects_if_api_raises_an_error_that_they_are_already_part_of_the_service(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
mocker,
api_user_active,
sample_invite,
Simplify test for API error with existing user This is now covered since we use 'mock_no_users_for_service'.
2021-05-25 17:27:30 +01:00
mock_get_existing_user_by_email,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
mock_accept_invite,
mock_get_service,
Add audit event for inviting users to a service
2021-03-05 12:19:36 +00:00
mock_get_user,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch(
"app.user_api_client.add_user_to_service",
side_effect=HTTPError(
response=Mock(
status_code=400,
json={
"result": "error",
"message": {
f"User id: {api_user_active['id']} already part of service id: {SERVICE_ONE_ID}"
},
},
),
message=f"User id: {api_user_active['id']} already part of service id: {SERVICE_ONE_ID}",
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
),
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
)
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=False,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for("main.service_dashboard", service_id=SERVICE_ONE_ID),
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
)
Catch errors when user register from invite API gives an error if it tries to add a user to a service and that user is already a member of the service. This situation shouldn't occur - admin checks if an invited user is a member of a service before calling API, but we have seen this error occurring when there are two requests processing at the same time. This change catches the errors from API if a user is already a member of a service and redirects the user to the service dashboard so that they don't see an error page.
2020-05-19 13:49:17 +01:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_existing_signed_out_user_accept_invite_redirects_to_sign_in(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
service_one,
api_user_active,
sample_invite,
mock_check_invite_token,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
mock_get_existing_user_by_email,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_add_user_to_service,
mock_accept_invite,
mock_get_service,
make sure invite tokens still check token on admin for error handler to kick in
2017-11-01 16:02:05 +00:00
mocker,
Add audit event for inviting users to a service
2021-03-05 12:19:36 +00:00
mock_events,
mock_get_user,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_service = service_one["id"]
expected_permissions = {
"view_activity",
"send_messages",
"manage_service",
"manage_api_keys",
}
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=True,
)
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_check_invite_token.assert_called_with("thisisnotarealtoken")
mock_get_existing_user_by_email.assert_called_with("invited_user@test.gsa.gov")
mock_add_user_to_service.assert_called_with(
expected_service,
api_user_active["id"],
expected_permissions,
sample_invite["folder_permissions"],
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_accept_invite.call_count == 1
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
assert (
page.h1.string,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
page.select("main p")[0].text.strip(),
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
) == (
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"You need to sign in again",
"We signed you out because you have not used Notify for a while.",
Show a more useful message if you get signed out > Users that allow their session to expire, or access a bookmarked link > are told they need to "Sign in to access this page" - we should > explain that it's because they've been away a while, so that they > understand why they're being asked to log in again. – https://www.pivotaltracker.com/story/show/140016919 The message we were showing before (Please log in to access this page is the default message from Flask Login). In order to stop this flash message from appearing, we need to override the default handler for when a user is unauthorised. We’re overriding it with the same behaviour, minus the flash message. If you navigate deliberately to the sign in page it’s unchanged. Content is Sheryll-approved.
2017-02-16 13:33:32 +00:00
)
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_new_user_accept_invite_calls_api_and_redirects_to_registration(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
service_one,
mock_check_invite_token,
mock_dont_get_user_by_email,
mock_add_user_to_service,
mock_get_service,
make sure invite tokens still check token on admin for error handler to kick in
2017-11-01 16:02:05 +00:00
mocker,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
_expected_redirect="/register-from-invite",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
)
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_check_invite_token.assert_called_with("thisisnotarealtoken")
mock_dont_get_user_by_email.assert_called_with("invited_user@test.gsa.gov")
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_new_user_accept_invite_calls_api_and_views_registration_page(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
service_one,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
sample_invite,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_check_invite_token,
mock_dont_get_user_by_email,
store invited user ids in session same as the invited org user ids in the previous commit
2021-03-08 12:51:35 +00:00
mock_get_invited_user_by_id,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_add_user_to_service,
mock_get_service,
make sure invite tokens still check token on admin for error handler to kick in
2017-11-01 16:02:05 +00:00
mocker,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=True,
)
Invited user email is shown on regiser from intive page but is not editable.
2016-03-07 11:55:18 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_check_invite_token.assert_called_with("thisisnotarealtoken")
mock_dont_get_user_by_email.assert_called_with("invited_user@test.gsa.gov")
mock_get_invited_user_by_id.assert_called_once_with(sample_invite["id"])
Invited user email is shown on regiser from intive page but is not editable.
2016-03-07 11:55:18 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert page.h1.string.strip() == "Create an account"
Invited user email is shown on regiser from intive page but is not editable.
2016-03-07 11:55:18 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert normalize_spaces(page.select_one("main p").text) == (
"Your account will be created with this email address: "
"invited_user@test.gsa.gov"
Stop email address wrapping
2018-07-02 09:16:48 +01:00
)
Display email address that invitee will be registered with. Also add flash message for users who already have an account.
2016-03-09 11:21:53 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
form = page.find("form")
name = form.find("input", id="name")
password = form.find("input", id="password")
service = form.find("input", type="hidden", id="service")
email = form.find("input", type="hidden", id="email_address")
Invited user email is shown on regiser from intive page but is not editable.
2016-03-07 11:55:18 +00:00
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert email
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert email.attrs["value"] == "invited_user@test.gsa.gov"
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert name
assert password
assert service
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert service.attrs["value"] == service_one["id"]
Invited user email is shown on regiser from intive page but is not editable.
2016-03-07 11:55:18 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_cancelled_invited_user_accepts_invited_redirect_to_cancelled_invitation(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_get_user,
mock_get_service,
Make a few more test files Pytest 5 compliant
2019-12-19 11:19:28 +00:00
sample_invite,
mock_check_invite_token,
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
mock_update_user_attribute.reset_mock()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["status"] = "cancelled"
page = client_request.get("main.accept_invite", token="thisisnotarealtoken")
Add cancelled-invite html. If a invited user accepts a cancelled invitation they are directed to a page telling them the invitation is cancelled. Without this they were able to register and were added to the service.
2016-03-04 14:42:52 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
app.invite_api_client.check_token.assert_called_with("thisisnotarealtoken")
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert page.h1.string.strip() == "The invitation you were sent has been cancelled"
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
# We don’t let people update `email_access_validated_at` using an
# cancelled invite
assert mock_update_user_attribute.called is False
Add cancelled-invite html. If a invited user accepts a cancelled invitation they are directed to a page telling them the invitation is cancelled. Without this they were able to register and were added to the service.
2016-03-04 14:42:52 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@pytest.mark.parametrize(
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
("admin_endpoint", "api_endpoint"),
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
[
("main.accept_invite", "app.invite_api_client.check_token"),
("main.accept_org_invite", "app.org_invite_api_client.check_token"),
],
)
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
def test_new_user_accept_invite_with_malformed_token(
move invite error handler to top level ensure we catch org errors as well as regular errors
2020-03-06 11:53:55 +00:00
admin_endpoint,
api_endpoint,
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
service_one,
mocker,
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch(
api_endpoint,
side_effect=HTTPError(
response=Mock(
status_code=400,
json={
"result": "error",
"message": {
"invitation": {
"Something’s wrong with this link. Make sure you’ve copied the whole thing."
}
},
},
),
message={
"invitation": "Something’s wrong with this link. Make sure you’ve copied the whole thing."
},
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
),
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
)
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
page = client_request.get(
admin_endpoint, token="thisisnotarealtoken", _follow_redirects=True
)
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert (
normalize_spaces(page.select_one(".banner-dangerous").text)
== "Something’s wrong with this link. Make sure you’ve copied the whole thing."
)
add catch for http error on invite token check
2018-03-08 12:47:24 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_new_user_accept_invite_completes_new_registration_redirects_to_verify(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
service_one,
sample_invite,
api_user_active,
mock_check_invite_token,
mock_dont_get_user_by_email,
invite-team-members
2018-02-19 16:53:29 +00:00
mock_email_is_not_already_in_use,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_register_user,
mock_send_verify_code,
store invited user ids in session same as the invited org user ids in the previous commit
2021-03-08 12:51:35 +00:00
mock_get_invited_user_by_id,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mock_accept_invite,
mock_add_user_to_service,
mock_get_service,
make sure invite tokens still check token on admin for error handler to kick in
2017-11-01 16:02:05 +00:00
mocker,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_redirect_location = "/register-from-invite"
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_expected_redirect=expected_redirect_location,
)
with client_request.session_transaction() as session:
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert session.get("invited_user_id") == sample_invite["id"]
data = {
"service": sample_invite["service"],
"email_address": sample_invite["email_address"],
"from_user": sample_invite["from_user"],
"password": "longpassword",
"mobile_number": "+12027890123",
"name": "Invited User",
"auth_type": "email_auth",
}
expected_redirect_location = "/verify"
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.post(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.register_from_invite",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_data=data,
_expected_redirect=expected_redirect_location,
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_send_verify_code.assert_called_once_with(ANY, "sms", data["mobile_number"])
mock_get_invited_user_by_id.assert_called_once_with(sample_invite["id"])
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_register_user.assert_called_with(
data["name"],
data["email_address"],
data["mobile_number"],
data["password"],
data["auth_type"],
)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert mock_accept_invite.call_count == 1
Change when invite gets marked as accepeted.
2016-06-08 11:52:26 +01:00
[WIP] New user can now accept invite and will be made to register. On succesful register and verfication they will be added to service and forwarded to dashboard. Nothing is done yet with the permissions requested in the invite to the user.
2016-03-02 15:25:04 +00:00
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
def test_signed_in_existing_user_cannot_use_anothers_invite(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
mocker,
api_user_active,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
Normalize whitespace in test arguments We have a bunch of different styles of handling when function definitions span multiple lines, which they almost always do with tests. Here’s why an argument per line, single indent is best: - cleaner diffs when you change the name of a method (one line change instead of multiple lines) - works better on narrow screens, eg Github’s diff view, or with two terminals side by side on a laptop screen - works with any editor’s indenting shortcuts, no need for an IDE Also, trailing comma in the list of arguments is good because adding a new argument to a method becomes a one line, not two line diff.
2017-02-03 10:42:01 +00:00
sample_invite,
mock_get_user,
mock_accept_invite,
mock_get_service,
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch(
"app.user_api_client.get_users_for_service", return_value=[api_user_active]
)
Removed some un needed flash messages raised as bugs. In the process found a couple of edge cases of incorrect use of invitation links by other users which are now handled.
2016-03-30 16:16:34 +01:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
page = client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
_follow_redirects=True,
_expected_status=403,
)
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert page.h1.string.strip() == "You’re not allowed to see this page"
flash_banners = page.find_all("div", class_="banner-dangerous")
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert len(flash_banners) == 1
Don’t allow unstyled links They should always be styled with the `govuk-link` class from GOV.UK Frontend, or another custom class.
2020-05-29 17:25:11 +01:00
banner_contents = normalize_spaces(flash_banners[0].text)
2767 passing
2022-08-05 00:25:03 -07:00
assert "You’re signed in as test@user.gsa.gov." in banner_contents
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert "This invite is for another email address." in banner_contents
assert "Sign out and click the link again to accept this invite." in banner_contents
assert mock_accept_invite.call_count == 0
Removed some un needed flash messages raised as bugs. In the process found a couple of edge cases of incorrect use of invitation links by other users which are now handled.
2016-03-30 16:16:34 +01:00
Make email addresses case insensitive when inviting users to services Email addresses in invites should be case insensitive. This is to stop the bug where a user creates their account using a lower case email address (e.g. user1@gov.uk), but is then invited to a service using their email address in a different case (e.g. USER1.gov.uk) and sees an error message telling them that they can't accept an invite for a different email address.
2017-12-21 16:42:16 +00:00
def test_accept_invite_does_not_treat_email_addresses_as_case_sensitive(
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request,
Make email addresses case insensitive when inviting users to services Email addresses in invites should be case insensitive. This is to stop the bug where a user creates their account using a lower case email address (e.g. user1@gov.uk), but is then invited to a service using their email address in a different case (e.g. USER1.gov.uk) and sees an error message telling them that they can't accept an invite for a different email address.
2017-12-21 16:42:16 +00:00
mocker,
api_user_active,
sample_invite,
mock_accept_invite,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_get_user_by_email,
Make email addresses case insensitive when inviting users to services Email addresses in invites should be case insensitive. This is to stop the bug where a user creates their account using a lower case email address (e.g. user1@gov.uk), but is then invited to a service using their email address in a different case (e.g. USER1.gov.uk) and sees an error message telling them that they can't accept an invite for a different email address.
2017-12-21 16:42:16 +00:00
):
2767 passing
2022-08-05 00:25:03 -07:00
# the email address of api_user_active is 'test@user.gsa.gov'
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = "TEST@user.gsa.gov"
mocker.patch("app.models.user.Users.client_method", return_value=[api_user_active])
Make email addresses case insensitive when inviting users to services Email addresses in invites should be case insensitive. This is to stop the bug where a user creates their account using a lower case email address (e.g. user1@gov.uk), but is then invited to a service using their email address in a different case (e.g. USER1.gov.uk) and sees an error message telling them that they can't accept an invite for a different email address.
2017-12-21 16:42:16 +00:00
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
_expected_status=302,
_expected_redirect=url_for(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.service_dashboard",
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
service_id=SERVICE_ONE_ID,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
),
Use `client_request` fixture where possible It: - saves repetetive boilerplate code - does some extra checks (eg checking for a `200` response) - makes the codebase less confusing to consistently do the same thing in the same way
2019-03-26 12:35:32 +00:00
)
Make email addresses case insensitive when inviting users to services Email addresses in invites should be case insensitive. This is to stop the bug where a user creates their account using a lower case email address (e.g. user1@gov.uk), but is then invited to a service using their email address in a different case (e.g. USER1.gov.uk) and sees an error message telling them that they can't accept an invite for a different email address.
2017-12-21 16:42:16 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
def test_new_invited_user_verifies_and_added_to_service(
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
service_one,
sample_invite,
api_user_active,
mock_check_invite_token,
mock_dont_get_user_by_email,
invite-team-members
2018-02-19 16:53:29 +00:00
mock_email_is_not_already_in_use,
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
mock_register_user,
mock_send_verify_code,
mock_check_verify_code,
mock_get_user,
mock_update_user_attribute,
mock_add_user_to_service,
mock_accept_invite,
mock_get_service,
store invited user ids in session same as the invited org user ids in the previous commit
2021-03-08 12:51:35 +00:00
mock_get_invited_user_by_id,
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
mock_get_service_templates,
mock_get_template_statistics,
Use new API endpoint for scheduled job stats Depends on: - [ ] https://github.com/alphagov/notifications-api/pull/2984
2020-09-28 14:28:23 +01:00
mock_has_no_jobs,
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
mock_has_permissions,
use service statistics endpoint instead of detailed service we're not actually looking at the detailed service aspects - just the stats. We're doing this in three places: * dashboard * notification activity page * when checking jobs to see if we're over the daily limit change these places to use a new api endpoint (service/id/statistics), which hopefully be a little more performant, and will definitely be a little more organised - moving away from generic endpoints with loads of optional parameters. We still need the detailed endpoints for the platform admin page tho. Depends on https://github.com/alphagov/notifications-api/pull/1865
2018-05-09 13:53:02 +01:00
mock_get_service_statistics,
Rename billing API methods to be recognisable I struggled to distinguish which was which as neither mentioned if the data they returned was monthly or annual.
2022-04-29 16:25:58 +01:00
mock_get_annual_usage_for_service,
Put usage summary back on the dashboard This reverts 1b1839ad301725c179a2f5b5d1fe43b66ea41e50, which removed the usage from the dashboard because it was causing performance problems: > **The yearly usage section on the dashboard page takes too log as a > result services with large yearly stats are timing out.** > > As a short term fix we have taken the yearly stats off the dashboard. > > There is a plan to create permanent statistic tables to warehouse the > data. The long term fix (the fact tables) is now in place, so it should be OK to bring this back. This is part of a wider piece of work to refresh the dashboard page now that jobs are moving to their own page.
2019-10-25 13:27:46 +01:00
mock_get_free_sms_fragment_limit,
don't swallow HTTP errors from create_event tests weren't patching out create_event (which is invoked every time a user logs in). This was getting caught by our egress proxy on jenkins. We didn't notice because the event handler code was swallowing all exceptions and not re-raising. This changes that code to no longer swallow exceptions. Since we did that, we also need to update all the tests that test log-in to mock the call
2018-05-02 10:27:01 +01:00
mock_create_event,
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
mocker,
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
# visit accept token page
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
_expected_redirect=url_for("main.register_from_invite"),
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
)
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
# get redirected to register from invite
data = {
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"service": sample_invite["service"],
"email_address": sample_invite["email_address"],
"from_user": sample_invite["from_user"],
"password": "longpassword",
"mobile_number": "+12027890123",
"name": "Invited User",
"auth_type": "sms_auth",
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
}
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.post(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.register_from_invite",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_data=data,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for("main.verify"),
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
)
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
# that sends user on to verify
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
page = client_request.post(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.verify",
_data={"sms_code": "123456"},
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_follow_redirects=True,
)
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
# when they post codes back to admin user should be added to
# service and sent on to dash board
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_permissions = {
"view_activity",
"send_messages",
"manage_service",
"manage_api_keys",
}
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
with client_request.session_transaction() as session:
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert "invited_user_id" not in session
new_user_id = session["user_id"]
mock_add_user_to_service.assert_called_with(
data["service"], new_user_id, expected_permissions, []
)
mock_accept_invite.assert_called_with(data["service"], sample_invite["id"])
mock_check_verify_code.assert_called_once_with(new_user_id, "123456", "sms")
assert service_one["id"] == session["service_id"]
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert page.find("h1").text == "Dashboard"
make big old test give some clues about where it fails by checking response codes of requests
2017-11-14 13:30:31 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@pytest.mark.parametrize(
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
("service_permissions", "trial_mode", "expected_endpoint", "extra_args"),
[
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
([], True, "main.service_dashboard", {}),
([], False, "main.service_dashboard", {}),
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
],
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
)
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
def test_new_invited_user_is_redirected_to_correct_place(
mocker,
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request,
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
sample_invite,
mock_check_invite_token,
mock_check_verify_code,
mock_get_user,
mock_dont_get_user_by_email,
mock_add_user_to_service,
mock_get_invited_user_by_id,
mock_events,
mock_get_service,
service_permissions,
trial_mode,
expected_endpoint,
extra_args,
):
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.logout()
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch(
"app.service_api_client.get_service",
return_value={
"data": service_json(
sample_invite["service"],
restricted=trial_mode,
permissions=service_permissions,
)
},
)
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_expected_status=302,
)
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
with client_request.session_transaction() as session:
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
session["user_details"] = {
"email": sample_invite["email_address"],
"id": sample_invite["id"],
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
}
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
client_request.post(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.verify",
_data={"sms_code": "123456"},
Replace uses of `client.get` and `client.post` We have a `client_request` fixture which does a bunch of useful stuff like: - checking the status code of the response - returning a `BeautifulSoup` object Lots of our tests still use an older fixture called `client`. This is not as good because it: - returns a raw `Response` object - doesn’t do the additional checks - means our tests contain a lot of repetetive boilerplate like `page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')` This commit converts all the tests which had a `client.get(…)` or `client.post(…)` statement to use their equivalents on `client_request` instead. Subsequent commits will remove uses of `client` in other tests, but doing it this way means the work can be broken up into more manageable chunks.
2022-01-04 15:40:42 +00:00
_expected_redirect=url_for(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
expected_endpoint, service_id=sample_invite["service"], **extra_args
),
Redirect newly-created users to broadcast tour
2021-05-19 10:56:13 +01:00
)
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
def test_existing_user_accepts_and_sets_email_auth(
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
client_request,
api_user_active,
service_one,
sample_invite,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
mock_get_existing_user_by_email,
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
mock_accept_invite,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
mock_update_user_attribute,
mock_add_user_to_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker,
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = api_user_active["email_address"]
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
service_one["permissions"].append("email_auth")
sample_invite["auth_type"] = "email_auth"
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
_expected_status=302,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for(
"main.service_dashboard", service_id=service_one["id"]
),
fix logged in user not having auth type set from invite
2017-11-15 14:59:03 +00:00
)
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_get_existing_user_by_email.assert_called_once_with("test@user.gsa.gov")
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
assert mock_update_user_attribute.call_args_list == [
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
call(api_user_active["id"], email_access_validated_at="2021-12-12T12:12:12"),
call(api_user_active["id"], auth_type="email_auth"),
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
]
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_add_user_to_service.assert_called_once_with(
ANY, api_user_active["id"], ANY, ANY
)
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
def test_platform_admin_user_accepts_and_preserves_auth(
client_request,
platform_admin_user,
service_one,
sample_invite,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
mock_accept_invite,
mock_add_user_to_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker,
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = platform_admin_user["email_address"]
sample_invite["auth_type"] = "email_auth"
service_one["permissions"].append("email_auth")
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch(
"app.user_api_client.get_user_by_email", return_value=platform_admin_user
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute = mocker.patch(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"app.user_api_client.update_user_attribute",
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
return_value=platform_admin_user,
)
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
client_request.login(platform_admin_user)
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
_expected_status=302,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for(
"main.service_dashboard", service_id=service_one["id"]
),
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute.assert_called_once_with(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
platform_admin_user["id"],
email_access_validated_at="2021-12-12T12:12:12",
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
)
Prevent switching auth type for Platform Admins This closes a security loophole, where the auth type of a Platform Admin could be unwittingly changed when they accept an invite, or by an admin of a service they are a member of.
2021-05-25 15:58:33 +01:00
assert mock_add_user_to_service.called
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
def test_existing_user_doesnt_get_auth_changed_by_service_without_permission(
client_request,
api_user_active,
service_one,
sample_invite,
mock_get_user_by_email,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
mock_accept_invite,
mock_update_user_attribute,
mock_add_user_to_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = api_user_active["email_address"]
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
assert "email_auth" not in service_one["permissions"]
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["auth_type"] = "email_auth"
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
_expected_status=302,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for(
"main.service_dashboard", service_id=service_one["id"]
),
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute.assert_called_once_with(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
api_user_active["id"],
email_access_validated_at="2021-12-12T12:12:12",
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
)
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
def test_existing_email_auth_user_without_phone_cannot_set_sms_auth(
client_request,
api_user_active,
service_one,
sample_invite,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
mock_accept_invite,
mock_update_user_attribute,
mock_add_user_to_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = api_user_active["email_address"]
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
service_one["permissions"].append("email_auth")
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
api_user_active["auth_type"] = "email_auth"
api_user_active["mobile_number"] = None
sample_invite["auth_type"] = "sms_auth"
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker.patch("app.user_api_client.get_user_by_email", return_value=api_user_active)
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
_expected_status=302,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for(
"main.service_dashboard", service_id=service_one["id"]
),
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
mock_update_user_attribute.assert_called_once_with(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
api_user_active["id"],
email_access_validated_at="2021-12-12T12:12:12",
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
)
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
More test config updates Note that this commit has some failing tests with it that also needed to be fixed; it is unclear why they are failing at the moment, though. Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
2023-09-25 17:55:42 -04:00
@pytest.mark.usefixtures("_mock_no_users_for_service")
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
@freeze_time("2021-12-12 12:12:12")
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
def test_existing_email_auth_user_with_phone_can_set_sms_auth(
client_request,
api_user_active,
service_one,
sample_invite,
Simplify mocking and asserting the existing user Previously we made surprising changed to the invited user as part of the mock, and then surprising assertions that its ID matched USER_ONE_ID. This simplifies the mock to do what it says, so that we can test for the original ID of the existing user.* *this does still differ from the ID of the sample_invite, which is also hard-coded to USER_ONE_ID. However, this isn't relevant in any of the tests, so doesn't seem to much of an issue.
2021-05-25 17:20:04 +01:00
mock_get_existing_user_by_email,
Use mock_check_invite_token consistently In some tests the mock was already used, and then overridden but without any change to the behaviour.
2021-05-25 17:54:37 +01:00
mock_check_invite_token,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
mock_accept_invite,
mock_update_user_attribute,
mock_add_user_to_service,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mocker,
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
):
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
sample_invite["email_address"] = api_user_active["email_address"]
service_one["permissions"].append("email_auth")
sample_invite["auth_type"] = "sms_auth"
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
client_request.get(
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
"main.accept_invite",
token="thisisnotarealtoken",
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
_expected_status=302,
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
_expected_redirect=url_for(
"main.service_dashboard", service_id=service_one["id"]
),
clean up logic around existing users accepting invites * if the service issuing the invite does not have permission to edit auth types, don't let them do anything. This will stop them turning existing email_auth users back to sms auth * if the user hasn't got a mobile number, but the invite is for sms login, don't do anything either. They won't have a phone number if they signed up via an email_auth invite previously. in these cases, we accept the invite and add the user to the service as normal, however, just don't update the user's auth type.
2017-11-15 17:19:32 +00:00
)
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
mock_get_existing_user_by_email.assert_called_once_with(
sample_invite["email_address"]
)
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
assert mock_update_user_attribute.call_args_list == [
notify-api-412 use black to enforce python coding style
2023-08-25 09:12:23 -07:00
call(api_user_active["id"], email_access_validated_at="2021-12-12T12:12:12"),
call(api_user_active["id"], auth_type="sms_auth"),
Update `email_access_validated_at` on invite Accepting an invite means that you’ve just clicked a link in your email inbox. This shows that you have access to your email. We can make a record of this, thereby extending the time before we ask you to revalidate your email address.
2021-08-17 16:38:37 +01:00
]
Reference in New Issue Copy Permalink