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
f55e2c06ef2a52282fdaf103f016011cd0ebdc71
notifications-admin/tests/app/main/views/test_manage_users.py

772 lines
24 KiB
Python
Raw Normal View History

Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
import copy
Refactor filtering out accepted invites to client None of our model or view layer code should need to know about accepted invites. We don’t use them anywhere because once an invite is accepted that person is now a user. Putting this logic in the client means that: - none of the code calling the client needs to care about accepted invites - it’s easier to (if we want) update the API code to not return accepted invites
2018-11-30 17:39:39 +00:00
import uuid
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 test to invite nonwhitelist user and refactor
2016-10-25 18:13:50 +01:00
import pytest
Manage user pages now surfaces invited users fetched from api.
2016-02-26 15:33:17 +00:00
from bs4 import BeautifulSoup
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
define isort first party (app and tests) we were seeing isort produce different outputs locally and in docker - this was due to it having different opinions about whether the tests module (ie all our unit tests) is a first party (local) or third party (pip installed) import. It's a first party import, so by defining this in the setup.cfg isort settings, we can force it to be consistent between environments. Note: I don't know why it was different in the first place though
2018-04-25 14:12:58 +01:00
import app
Split models to prevent circular imports This commit is the first step to disentangling the models from the API clients. With the models in the same folder as the API clients it makes it hard to import the API clients within the model without getting a circular import. After this commit the user API clients still has this problem, but at least the service API client doesn’t.
2018-10-26 15:58:44 +01:00
from app.models.user import InvitedUser
define isort first party (app and tests) we were seeing isort produce different outputs locally and in docker - this was due to it having different opinions about whether the tests module (ie all our unit tests) is a first party (local) or third party (pip installed) import. It's a first party import, so by defining this in the setup.cfg isort settings, we can force it to be consistent between environments. Note: I don't know why it was different in the first place though
2018-04-25 14:12:58 +01:00
from app.utils import is_gov_user
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
from tests.conftest import (
SERVICE_ONE_ID,
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
active_caseworking_user,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
active_user_empty_permissions,
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
active_user_manage_template_permission,
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
active_user_no_mobile,
active_user_view_permissions,
active_user_with_permissions,
normalize_spaces,
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
)
fix imports
2018-03-02 11:09:23 +00:00
from tests.conftest import service_one as create_sample_service
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 pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
@pytest.mark.parametrize('user, expected_self_text, expected_coworker_text', [
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
(
active_user_with_permissions,
(
'Test User (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can Manage API integration'
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
),
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
(
'ZZZZZZZZ zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration '
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
'Edit permissions'
)
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
),
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
(
active_user_empty_permissions,
(
'Test User With Empty Permissions (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
),
(
'ZZZZZZZZ zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
),
),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
(
active_user_view_permissions,
(
'Test User With Permissions (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
),
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
(
'ZZZZZZZZ zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
)
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
),
(
active_user_manage_template_permission,
(
'Test User With Permissions (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
),
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
(
'ZZZZZZZZ zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
)
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
),
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
(
active_user_manage_template_permission,
(
'Test User With Permissions (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
),
(
'ZZZZZZZZ zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
)
),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01: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
def test_should_show_overview_page(
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01: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,
mock_get_invites_for_service,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
mock_has_no_jobs,
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
fake_uuid,
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
service_one,
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
user,
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
expected_self_text,
expected_coworker_text,
active_user_view_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
):
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
current_user = user(fake_uuid)
other_user = copy.deepcopy(active_user_view_permissions)
other_user.email_address = 'zzzzzzz@example.gov.uk'
other_user.name = 'ZZZZZZZZ'
other_user.id = 'zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz'
mocker.patch('app.user_api_client.get_user', return_value=current_user)
mocker.patch('app.user_api_client.get_users_for_service', return_value=[
current_user,
other_user,
])
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
page = client_request.get('main.manage_users', service_id=SERVICE_ONE_ID)
[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
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
assert normalize_spaces(page.select_one('h1').text) == 'Team members'
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
assert normalize_spaces(page.select('.user-list-item')[0].text) == expected_self_text
# [1:5] are invited users
assert normalize_spaces(page.select('.user-list-item')[6].text) == expected_coworker_text
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
app.user_api_client.get_users_for_service.assert_called_once_with(service_id=SERVICE_ONE_ID)
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
def test_should_show_caseworker_on_overview_page(
client_request,
mocker,
mock_get_invites_for_service,
fake_uuid,
service_one,
):
service_one['permissions'].append('caseworking')
current_user = active_user_view_permissions(active_user_view_permissions)
other_user = active_caseworking_user(fake_uuid)
other_user.email_address = 'zzzzzzz@example.gov.uk'
mocker.patch('app.user_api_client.get_user', return_value=current_user)
mocker.patch('app.user_api_client.get_users_for_service', return_value=[
current_user,
other_user,
])
page = client_request.get('main.manage_users', service_id=SERVICE_ONE_ID)
assert normalize_spaces(page.select_one('h1').text) == 'Team members'
assert normalize_spaces(page.select('.user-list-item')[0].text) == (
'Test User With Permissions (you) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can’t Send messages '
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
)
# [1:5] are invited users
assert normalize_spaces(page.select('.user-list-item')[6].text) == (
'Test User zzzzzzz@example.gov.uk '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t See dashboard '
'Can Send messages '
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
)
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
@pytest.mark.parametrize('endpoint, extra_args, service_has_email_auth, auth_options_hidden', [
(
'main.edit_user_permissions',
{'user_id': 0},
True,
False
),
(
'main.edit_user_permissions',
{'user_id': 0},
False,
True
),
(
'main.invite_user',
{},
True,
False
),
(
'main.invite_user',
{},
False,
True
)
])
def test_service_with_no_email_auth_hides_auth_type_options(
client_request,
endpoint,
extra_args,
service_has_email_auth,
auth_options_hidden,
service_one
):
if service_has_email_auth:
service_one['permissions'].append('email_auth')
page = client_request.get(endpoint, service_id=service_one['id'], **extra_args)
assert (page.find('input', attrs={"name": "login_authentication"}) is None) == auth_options_hidden
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
@pytest.mark.parametrize('service_has_caseworking', (True, False))
@pytest.mark.parametrize('endpoint, extra_args', [
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
(
'main.edit_user_permissions',
{'user_id': 0},
),
(
'main.invite_user',
{},
),
])
def test_service_without_caseworking_doesnt_show_admin_vs_caseworker(
client_request,
endpoint,
service_has_caseworking,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
extra_args,
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
):
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
page = client_request.get(
endpoint,
service_id=SERVICE_ONE_ID,
**extra_args
)
assert page.select('input[type=checkbox]')[0]['name'] == 'view_activity'
assert page.select('input[type=checkbox]')[1]['name'] == 'send_messages'
assert page.select('input[type=checkbox]')[2]['name'] == 'manage_templates'
assert page.select('input[type=checkbox]')[3]['name'] == 'manage_service'
assert page.select('input[type=checkbox]')[4]['name'] == 'manage_api_keys'
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
@pytest.mark.parametrize('service_has_email_auth, displays_auth_type', [
(True, True),
(False, False)
])
def test_manage_users_page_shows_member_auth_type_if_service_has_email_auth_activated(
client_request,
service_has_email_auth,
service_one,
mock_get_users_by_service,
mock_get_invites_for_service,
displays_auth_type
):
if service_has_email_auth:
service_one['permissions'].append('email_auth')
page = client_request.get('main.manage_users', service_id=service_one['id'])
assert bool(page.select_one('.tick-cross-list-hint')) == displays_auth_type
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
@pytest.mark.parametrize('user, sms_option_disabled, expected_label', [
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
(
active_user_no_mobile,
True,
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
"""
Text message code
Not available because this team member hasn’t added a
phone number to their profile
""",
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
),
(
active_user_with_permissions,
False,
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
"""
Text message code
""",
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
),
])
def test_user_with_no_mobile_number_cant_be_set_to_sms_auth(
client_request,
user,
sms_option_disabled,
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
expected_label,
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
service_one,
mocker
):
service_one['permissions'].append('email_auth')
test_user = mocker.patch('app.user_api_client.get_user', return_value=user(mocker))
page = client_request.get(
'main.edit_user_permissions',
service_id=service_one['id'],
user_id=test_user.id
)
sms_auth_radio_button = page.select_one('input[value="sms_auth"]')
assert sms_auth_radio_button.has_attr("disabled") == sms_option_disabled
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
assert normalize_spaces(
page.select_one('label[for=login_authentication-0]').text
) == normalize_spaces(expected_label)
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
@pytest.mark.parametrize('endpoint, extra_args, expected_checkboxes', [
(
'main.edit_user_permissions',
{'user_id': 0},
[
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
('view_activity', True),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
('send_messages', True),
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
('manage_templates', True),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
('manage_service', True),
('manage_api_keys', True),
]
),
(
'main.invite_user',
{},
[
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
('view_activity', False),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
('send_messages', False),
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
('manage_templates', False),
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
('manage_service', False),
('manage_api_keys', False),
]
),
])
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
def test_should_show_page_for_one_user(
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
client_request,
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
endpoint,
extra_args,
expected_checkboxes,
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
):
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
page = client_request.get(endpoint, service_id=SERVICE_ONE_ID, **extra_args)
checkboxes = page.select('input[type=checkbox]')
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
assert len(checkboxes) == 5
Test that the right permissions in page This commit makes sure that the right permission choices are shown in these pages: - manage team page - invite a user page - edit permissions page This is in order to make changing these pages easier (see subsequent commits).
2017-08-17 10:49:21 +01:00
for index, expected in enumerate(expected_checkboxes):
expected_input_name, expected_checked = expected
assert checkboxes[index]['name'] == expected_input_name
assert checkboxes[index].has_attr('checked') == expected_checked
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
@pytest.mark.parametrize('submitted_permissions, permissions_sent_to_api', [
(
{
'view_activity': 'y',
'send_messages': 'y',
'manage_templates': 'y',
'manage_service': 'y',
'manage_api_keys': 'y',
},
{
'view_activity',
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
'send_messages',
'manage_service',
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'manage_templates',
'manage_api_keys',
}
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
),
(
{
'view_activity': 'y',
'send_messages': 'y',
'manage_templates': '',
},
{
'view_activity',
'send_messages',
}
),
(
{},
set(),
),
])
def test_edit_user_permissions(
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,
mock_get_invites_for_service,
mock_set_user_permissions,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
fake_uuid,
submitted_permissions,
permissions_sent_to_api,
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
):
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
client_request.post(
'main.edit_user_permissions',
service_id=SERVICE_ONE_ID,
user_id=fake_uuid,
_data=dict(
email_address="test@example.com",
**submitted_permissions
),
_expected_status=302,
_expected_redirect=url_for(
'main.manage_users',
service_id=SERVICE_ONE_ID,
_external=True,
),
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
)
mock_set_user_permissions.assert_called_with(
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
fake_uuid,
SERVICE_ONE_ID,
permissions=permissions_sent_to_api,
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
)
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
@pytest.mark.parametrize('auth_type', ['email_auth', 'sms_auth'])
def test_edit_user_permissions_including_authentication_with_email_auth_service(
logged_in_client,
active_user_with_permissions,
mocker,
mock_get_invites_for_service,
mock_set_user_permissions,
mock_update_user_attribute,
service_one,
auth_type
):
service_one['permissions'].append('email_auth')
response = logged_in_client.post(
url_for(
'main.edit_user_permissions',
service_id=service_one['id'],
user_id=active_user_with_permissions.id
),
data={
'email_address': active_user_with_permissions.email_address,
'send_messages': 'y',
'manage_templates': 'y',
'manage_service': 'y',
'manage_api_keys': 'y',
'login_authentication': auth_type
}
)
mock_set_user_permissions.assert_called_with(
str(active_user_with_permissions.id),
service_one['id'],
permissions={
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
'send_messages',
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
'manage_templates',
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
'manage_service',
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
'manage_api_keys',
}
)
mock_update_user_attribute.assert_called_with(
str(active_user_with_permissions.id),
auth_type=auth_type
)
assert response.status_code == 302
assert response.location == url_for(
'main.manage_users', service_id=service_one['id'], _external=True
)
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
def test_should_show_page_for_inviting_user(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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
active_user_with_permissions,
mocker,
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +00:00
):
Remove whitelist user fixture and refactor
2016-10-26 14:15:55 +01:00
service = create_sample_service(active_user_with_permissions)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
response = logged_in_client.get(url_for('main.invite_user', service_id=service['id']))
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +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 'Invite a team member' in response.get_data(as_text=True)
assert response.status_code == 200
Add pages to invite, edit, and delete users This takes the original prototype version of this page, and, using the same fake data (ie nothing is wired up): - adds an invite users page - adds an edit (and delete) user page Both these pages allow the user to set another user’s permissions. This commit adds images for the ticks and crosses, so we have control over their appearance.
2016-02-19 15:02:13 +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
Add tests to ensure non gov user cannot see, access or create service
2016-10-28 10:48:29 +01:00
@pytest.mark.parametrize('email_address, gov_user', [
Add test to invite nonwhitelist user and refactor
2016-10-25 18:13:50 +01:00
('test@example.gov.uk', True),
('test@nonwhitelist.com', False)
])
[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
def test_invite_user(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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
active_user_with_permissions,
mocker,
sample_invite,
email_address,
gov_user,
[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
):
Remove whitelist user fixture and refactor
2016-10-26 14:15:55 +01:00
service = create_sample_service(active_user_with_permissions)
[WIP]: fixing unit tests
2016-03-18 10:49:22 +00:00
sample_invite['email_address'] = 'test@example.gov.uk'
[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]: fixing unit tests
2016-03-18 10:49:22 +00:00
data = [InvitedUser(**sample_invite)]
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert is_gov_user(email_address) == gov_user
mocker.patch('app.invite_api_client.get_invites_for_service', return_value=data)
mocker.patch('app.user_api_client.get_users_for_service', return_value=[active_user_with_permissions])
mocker.patch('app.invite_api_client.create_invite', return_value=InvitedUser(**sample_invite))
response = logged_in_client.post(
url_for('main.invite_user', service_id=service['id']),
data={'email_address': email_address,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'view_activity': 'y',
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'send_messages': 'y',
Add a fourth, ‘manage templates’ permission We’ve seen from research (a long time ago) that the ‘manage service’ permission is too broad, and gives too much control to someone who only needs the ability to edit templates. In other words, editing content should be its own, separate permission, rather than being rolled up into manage service. Since this is already disaggregated on the API side, making this change just means changing the mapping on the admin side and adding an extra checkbox on the invite/edit page. Which is what this commit does. So for now, an existing user who has the manage service permission gets both manage service and manage templates (ie no change to what they can do). Newly invited users will get to choose if they have both, either, or neither.
2017-08-17 11:14:26 +01:00
'manage_templates': 'y',
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
'manage_service': 'y',
'manage_api_keys': 'y'},
follow_redirects=True
)
assert response.status_code == 200
page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')
assert page.h1.string.strip() == 'Team members'
flash_banner = page.find('div', class_='banner-default-with-tick').string.strip()
assert flash_banner == 'Invite sent to test@example.gov.uk'
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
expected_permissions = {'manage_api_keys', 'manage_service', 'manage_templates', 'send_messages', 'view_activity'}
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
app.invite_api_client.create_invite.assert_called_once_with(sample_invite['from_user'],
sample_invite['service'],
email_address,
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
expected_permissions,
'sms_auth')
@pytest.mark.parametrize('auth_type', [
('sms_auth'),
('email_auth')
])
@pytest.mark.parametrize('email_address, gov_user', [
('test@example.gov.uk', True),
('test@nonwhitelist.com', False)
])
def test_invite_user_with_email_auth_service(
logged_in_client,
active_user_with_permissions,
sample_invite,
email_address,
gov_user,
mocker,
service_one,
auth_type
):
service_one['permissions'].append('email_auth')
sample_invite['email_address'] = 'test@example.gov.uk'
data = [InvitedUser(**sample_invite)]
assert is_gov_user(email_address) == gov_user
mocker.patch('app.invite_api_client.get_invites_for_service', return_value=data)
mocker.patch('app.user_api_client.get_users_for_service', return_value=[active_user_with_permissions])
mocker.patch('app.invite_api_client.create_invite', return_value=InvitedUser(**sample_invite))
response = logged_in_client.post(
url_for('main.invite_user', service_id=service_one['id']),
data={'email_address': email_address,
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
'view_activity': 'y',
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
'send_messages': 'y',
'manage_templates': 'y',
'manage_service': 'y',
'manage_api_keys': 'y',
'login_authentication': auth_type},
follow_redirects=True
)
assert response.status_code == 200
page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')
assert page.h1.string.strip() == 'Team members'
flash_banner = page.find('div', class_='banner-default-with-tick').string.strip()
assert flash_banner == 'Invite sent to test@example.gov.uk'
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
expected_permissions = {'manage_api_keys', 'manage_service', 'manage_templates', 'send_messages', 'view_activity'}
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
app.invite_api_client.create_invite.assert_called_once_with(sample_invite['from_user'],
sample_invite['service'],
email_address,
expected_permissions,
auth_type)
Add button to cancel invitation of invited user.
2016-03-01 16:12:26 +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_cancel_invited_user_cancels_user_invitations(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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
active_user_with_permissions,
mocker,
):
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
mocker.patch('app.invite_api_client.cancel_invited_user')
import uuid
invited_user_id = uuid.uuid4()
service = create_sample_service(active_user_with_permissions)
response = logged_in_client.get(url_for('main.cancel_invited_user', service_id=service['id'],
invited_user_id=invited_user_id))
Add button to cancel invitation of invited user.
2016-03-01 16:12:26 +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 response.status_code == 302
assert response.location == url_for('main.manage_users', service_id=service['id'], _external=True)
Filter out accepted invites from manage users page Added basic test of invite client.
2016-03-07 10:19:44 +00:00
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
@pytest.mark.parametrize('invite_status, expected_text', [
('pending', (
'invited_user@test.gov.uk (invited) '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can See dashboard '
'Can Send messages '
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can Manage API integration '
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
'Cancel invitation'
)),
('cancelled', (
'invited_user@test.gov.uk (cancelled invite) '
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
# all permissions are greyed out
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t See dashboard '
'Can’t Send messages '
remove all instances of db style permissions lots of renaming of send_texts/emails/letters to send_messages, and manage_settings/users to manage_service
2018-02-28 17:22:20 +00:00
'Can’t Add and edit templates '
Make the permission labels shorter They were feeling a bit heavy on the _Team members_ page. We can remove some words without losing any meaning.
2018-08-08 14:23:24 +01:00
'Can’t Manage settings, team and usage '
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
'Can’t Manage API integration'
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +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_manage_users_shows_invited_user(
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01: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,
active_user_with_permissions,
sample_invite,
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
invite_status,
expected_text,
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
):
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
sample_invite['status'] = invite_status
Filter out accepted invites from manage users page Added basic test of invite client.
2016-03-07 10:19:44 +00:00
data = [InvitedUser(**sample_invite)]
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
mocker.patch('app.invite_api_client.get_invites_for_service', return_value=data)
mocker.patch('app.user_api_client.get_users_for_service', return_value=[active_user_with_permissions])
Filter out accepted invites from manage users page Added basic test of invite client.
2016-03-07 10:19:44 +00:00
Make existing tests use ``client_request fixture This commit makes the existing tests around user permissions less verbose by using the new `client_request` fixture. This fixture takes care of: - setting up a service - asserting that the response is `200` It also tests that the page titles, some of which didn’t match with the `<h1>`s, so this commit also fixes that mismatch.
2017-08-17 10:44:36 +01:00
page = client_request.get('main.manage_users', service_id=SERVICE_ONE_ID)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert page.h1.string.strip() == 'Team members'
Change display of cancelled users, fix edit link It’s confusing showing green ticks for cancelled invites. This commit changes the appearance so that only pending or active users (ie those that could actually do some damage) get green ticks. Also fixes missing edit links caused by instances of `User` having `.state` but instances of `InvitedUser` having `.status`. Right now these are two separate lists. Which makes it harder to add improvements that will make large numbers of users easier to manage.
2018-01-26 17:14:00 +00:00
assert normalize_spaces(page.select('.user-list-item')[0].text) == expected_text
Filter out accepted invites in template not client.
2016-03-07 13:59:54 +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_manage_users_does_not_show_accepted_invite(
Refactor filtering out accepted invites to client None of our model or view layer code should need to know about accepted invites. We don’t use them anywhere because once an invite is accepted that person is now a user. Putting this logic in the client means that: - none of the code calling the client needs to care about accepted invites - it’s easier to (if we want) update the API code to not return accepted invites
2018-11-30 17:39:39 +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,
active_user_with_permissions,
sample_invite,
):
Filter out accepted invites in template not client.
2016-03-07 13:59:54 +00:00
invited_user_id = uuid.uuid4()
sample_invite['id'] = invited_user_id
sample_invite['status'] = 'accepted'
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
mocker.patch('app.user_api_client.get_users_for_service', return_value=[active_user_with_permissions])
Refactor filtering out accepted invites to client None of our model or view layer code should need to know about accepted invites. We don’t use them anywhere because once an invite is accepted that person is now a user. Putting this logic in the client means that: - none of the code calling the client needs to care about accepted invites - it’s easier to (if we want) update the API code to not return accepted invites
2018-11-30 17:39:39 +00:00
mocker.patch('app.invite_api_client._get_invites_for_service', return_value=[sample_invite])
Filter out accepted invites in template not client.
2016-03-07 13:59:54 +00:00
Refactor filtering out accepted invites to client None of our model or view layer code should need to know about accepted invites. We don’t use them anywhere because once an invite is accepted that person is now a user. Putting this logic in the client means that: - none of the code calling the client needs to care about accepted invites - it’s easier to (if we want) update the API code to not return accepted invites
2018-11-30 17:39:39 +00:00
page = client_request.get('main.manage_users', service_id=SERVICE_ONE_ID)
Filter out accepted invites in template not client.
2016-03-07 13:59:54 +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 page.h1.string.strip() == 'Team members'
user_lists = page.find_all('div', {'class': 'user-list'})
assert len(user_lists) == 1
assert not page.find(text='invited_user@test.gov.uk')
Added validation to ensure user can't invite themselves. Refactored Invited user form into permissions and invite forms for use in invite and edit permissions. Added template for edit permissions.
2016-03-09 13:00:52 +00:00
def test_user_cant_invite_themselves(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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,
active_user_with_permissions,
mock_create_invite,
Added validation to ensure user can't invite themselves. Refactored Invited user form into permissions and invite forms for use in invite and edit permissions. Added template for edit permissions.
2016-03-09 13:00:52 +00:00
):
Remove whitelist user fixture and refactor
2016-10-26 14:15:55 +01:00
service = create_sample_service(active_user_with_permissions)
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
response = logged_in_client.post(
url_for('main.invite_user', service_id=service['id']),
data={'email_address': active_user_with_permissions.email_address,
'send_messages': 'y',
'manage_service': 'y',
'manage_api_keys': 'y'},
follow_redirects=True
)
assert response.status_code == 200
page = BeautifulSoup(response.data.decode('utf-8'), 'html.parser')
assert page.h1.string.strip() == 'Invite a team member'
form_error = page.find('span', class_='error-message').string.strip()
assert form_error == "You can’t send an invitation to yourself"
assert not mock_create_invite.called
Manage team, now has a view only version of the page which requires no permissions.
2016-03-21 15:25:19 +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_no_permission_manage_users_page(
use client_request to always check the response this'll avoid us accidentally 503ing and ignoring it in tests where we check for "assert my_content not present"
2018-05-03 17:00:05 +01: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,
use client_request to always check the response this'll avoid us accidentally 503ing and ignoring it in tests where we check for "assert my_content not present"
2018-05-03 17:00:05 +01:00
mock_get_users_by_service,
mock_get_invites_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
api_user_active,
mocker,
):
use client_request to always check the response this'll avoid us accidentally 503ing and ignoring it in tests where we check for "assert my_content not present"
2018-05-03 17:00:05 +01:00
resp_text = client_request.get('main.manage_users', service_id=service_one['id'])
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
assert url_for('.invite_user', service_id=service_one['id']) not in resp_text
assert "Edit permission" not in resp_text
assert "Team members" not in resp_text
Functionality added and all tests working. Update correct use of permissions form.
2016-03-23 10:46:31 +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_get_remove_user_from_service(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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
active_user_with_permissions,
service_one,
mocker,
):
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
response = logged_in_client.get(
url_for(
'main.remove_user_from_service',
service_id=service_one['id'],
user_id=active_user_with_permissions.id))
assert response.status_code == 200
assert "Are you sure you want to remove" in response.get_data(as_text=True)
assert "Remove user from service" in response.get_data(as_text=True)
Functionality added and all tests working. Update correct use of permissions form.
2016-03-23 10:46:31 +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_remove_user_from_service(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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
active_user_with_permissions,
service_one,
mocker,
mock_get_users_by_service,
mock_get_user,
mock_remove_user_from_service,
):
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
response = logged_in_client.post(
url_for(
'main.remove_user_from_service',
service_id=service_one['id'],
user_id=active_user_with_permissions.id))
assert response.status_code == 302
assert response.location == url_for(
'main.manage_users', service_id=service_one['id'], _external=True)
mock_remove_user_from_service.assert_called_once_with(service_one['id'],
str(active_user_with_permissions.id))
Allow platform admin to edit users.
2016-09-30 11:48:16 +01:00
def test_can_remove_user_from_service_as_platform_admin(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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,
platform_admin_user,
active_user_with_permissions,
mock_remove_user_from_service,
mocker,
):
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
response = logged_in_client.post(
url_for(
'main.remove_user_from_service',
service_id=service_one['id'],
user_id=active_user_with_permissions.id))
assert response.status_code == 302
assert response.location == url_for(
'main.manage_users', service_id=service_one['id'], _external=True)
mock_remove_user_from_service.assert_called_once_with(service_one['id'],
str(active_user_with_permissions.id))
Added invite user button for platform admins on any service
2016-06-03 11:10:38 +01:00
def test_can_invite_user_as_platform_admin(
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
logged_in_client,
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,
platform_admin_user,
active_user_with_permissions,
mock_get_invites_for_service,
mocker,
):
Use `client` and `logged_in_client` fixtures Wherever possible, because Don’t Repeat Yourself.
2017-02-03 12:07:21 +00:00
mocker.patch('app.user_api_client.get_users_for_service', return_value=[active_user_with_permissions])
response = logged_in_client.get(url_for('main.manage_users', service_id=service_one['id']))
resp_text = response.get_data(as_text=True)
assert url_for('.invite_user', service_id=service_one['id']) in resp_text
Reference in New Issue Copy Permalink