Initial QSfera import
This commit is contained in:
Курнат Андрей
@@ -0,0 +1,441 @@
|
||||
Feature: add users to group
|
||||
As a admin
|
||||
I want to be able to add users to a group
|
||||
So that I can give a user access to the resources of the group
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
|
||||
Scenario: adding a user to a group
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| simplegroup | nothing special here |
|
||||
| España§àôœ€ | special European and other characters |
|
||||
| नेपाली | Unicode group name |
|
||||
When the administrator adds the following users to the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | simplegroup |
|
||||
| Alice | España§àôœ€ |
|
||||
| Alice | नेपाली |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Alice | simplegroup |
|
||||
| Alice | España§àôœ€ |
|
||||
| Alice | नेपाली |
|
||||
|
||||
|
||||
Scenario: adding a user to a group with special character in its name
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| brand-new-group | dash |
|
||||
| the.group | dot |
|
||||
| left,right | comma |
|
||||
| 0 | The "false" group |
|
||||
| Finance (NP) | Space and brackets |
|
||||
| Admin&Finance | Ampersand |
|
||||
| maint+eng | Plus sign |
|
||||
| $x<=>[y*z^2]! | Maths symbols |
|
||||
| 😁 😂 | emoji |
|
||||
| admin:Pokhara@Nepal | Colon and @ |
|
||||
When the administrator adds the following users to the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | the.group |
|
||||
| Alice | left,right |
|
||||
| Alice | 0 |
|
||||
| Alice | Finance (NP) |
|
||||
| Alice | Admin&Finance |
|
||||
| Alice | maint+eng |
|
||||
| Alice | $x<=>[y*z^2]! |
|
||||
| Alice | 😁 😂 |
|
||||
| Alice | admin:Pokhara@Nepal |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | the.group |
|
||||
| Alice | left,right |
|
||||
| Alice | 0 |
|
||||
| Alice | Finance (NP) |
|
||||
| Alice | Admin&Finance |
|
||||
| Alice | maint+eng |
|
||||
| Alice | $x<=>[y*z^2]! |
|
||||
| Alice | 😁 😂 |
|
||||
| Alice | admin:Pokhara@Nepal |
|
||||
|
||||
|
||||
Scenario: adding a user to a group with % and # in its name
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| maintenance#123 | Hash sign |
|
||||
| 50%pass | Percent sign (special escaping happens) |
|
||||
| 50%25=0 | %25 literal looks like an escaped "%" |
|
||||
| 50%2Eagle | %2E literal looks like an escaped "." |
|
||||
| 50%2Fix | %2F literal looks like an escaped slash |
|
||||
| Mgmt\Middle | Backslash |
|
||||
| staff?group | Question mark |
|
||||
When the administrator adds the following users to the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | maintenance#123 |
|
||||
| Alice | 50%pass |
|
||||
| Alice | 50%25=0 |
|
||||
| Alice | 50%2Eagle |
|
||||
| Alice | 50%2Fix |
|
||||
| Alice | Mgmt\Middle |
|
||||
| Alice | staff?group |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Alice | maintenance#123 |
|
||||
| Alice | 50%pass |
|
||||
| Alice | 50%25=0 |
|
||||
| Alice | 50%2Eagle |
|
||||
| Alice | 50%2Fix |
|
||||
| Alice | Mgmt\Middle |
|
||||
| Alice | staff?group |
|
||||
|
||||
|
||||
Scenario: adding a user to a group that has a forward-slash in the group name
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| Mgmt/Sydney | Slash (special escaping happens) |
|
||||
| Mgmt//NSW/Sydney | Multiple slash |
|
||||
| priv/subadmins/1 | Subadmins mentioned not at the end |
|
||||
| var/../etc | using slash-dot-dot |
|
||||
When the administrator adds the following users to the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | Mgmt/Sydney |
|
||||
| Alice | Mgmt//NSW/Sydney |
|
||||
| Alice | priv/subadmins/1 |
|
||||
| Alice | var/../etc |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Alice | Mgmt/Sydney |
|
||||
| Alice | Mgmt//NSW/Sydney |
|
||||
| Alice | priv/subadmins/1 |
|
||||
| Alice | var/../etc |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin tries to add herself to a group
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
And group "groupA" has been created
|
||||
When user "Alice" tries to add herself to group "groupA" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin tries to add other user to a group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "groupA" has been created
|
||||
When user "Alice" tries to add user "Brian" to group "groupA" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message" : {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin tries to add user to a nonexistent group
|
||||
When the administrator tries to add user "Alice" to a nonexistent group using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
@issue-5939
|
||||
Scenario Outline: user other than the admin tries to add user to a nonexistent group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" tries to add user "Brian" to a nonexistent group using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin tries to add a nonexistent user to a group
|
||||
Given group "groupA" has been created
|
||||
When the administrator tries to add nonexistent user to group "groupA" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: non-admin user tries to add a nonexistent user to a group
|
||||
Given group "groupA" has been created
|
||||
When user "Alice" tries to add nonexistent user to group "groupA" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
|
||||
|
||||
Scenario: admin tries to add user to a group without sending the group
|
||||
When the administrator tries to add user "Alice" to a nonexistent group using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: add multiple users to a group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" adds the following users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Brian | grp1 |
|
||||
| Carol | grp1 |
|
||||
|
||||
|
||||
Scenario: admin tries to add users to a nonexistent group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
When the administrator "Alice" tries to add the following users to a nonexistent group at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: admin tries to add multiple nonexistent users to a group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" tries to add the following nonexistent users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: admin tries to add nonexistent and existing users to a group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" tries to add the following existent and nonexistent users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: adding a disabled user to a group
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| sales | normal group |
|
||||
And the user "Admin" has disabled user "Alice"
|
||||
When the administrator adds the following users to the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | sales |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Alice | sales |
|
||||
|
||||
@issue-5702
|
||||
Scenario: try to add users to a group twice
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
And the administrator "Alice" has added the following users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
When the administrator "Alice" adds the following users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "400"
|
||||
And the following users should be listed in the following groups
|
||||
| username | groupname |
|
||||
| Brian | grp1 |
|
||||
| Carol | grp1 |
|
||||
|
||||
@issue-5793
|
||||
Scenario: try to add a group to another group with PATCH request
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And these groups have been created:
|
||||
| groupname |
|
||||
| student |
|
||||
| music |
|
||||
And user "Brian" has been added to group "music"
|
||||
When the administrator "Alice" tries to add a group "music" to another group "student" with PATCH request using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
@issue-5793
|
||||
Scenario: try to add a group to another group with POST request
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And these groups have been created:
|
||||
| groupname |
|
||||
| student |
|
||||
| music |
|
||||
And user "Brian" has been added to group "music"
|
||||
When the administrator "Alice" tries to add a group "music" to another group "student" with POST request using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
|
||||
Scenario Outline: admin tries to add a user to a group with invalid JSON
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When user "Alice" tries to add user "Brian" to group "grp1" with invalid JSON "<invalid-json>" using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
Examples:
|
||||
| invalid-json |
|
||||
| {'@odata.id': 'https://localhost:9200/graph/v1.0/users/%user_id%',} |
|
||||
| {'@odata.id'- 'https://localhost:9200/graph/v1.0/users/%user_id%'} |
|
||||
| {@odata.id: https://localhost:9200/graph/v1.0/users/%user_id%} |
|
||||
|
||||
|
||||
Scenario Outline: admin tries to add multiple users to a group at once with invalid JSON
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When user "Alice" tries to add the following users to a group "grp1" at once with invalid JSON "<invalid-json>" using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "400"
|
||||
Examples:
|
||||
| invalid-json |
|
||||
| {'members@odata.bind': ['https://localhost:9200/graph/v1.0/users/%user_id%',,'https://localhost:9200/graph/v1.0/users/%user_id%']} |
|
||||
| {'members@odata.bind'- ['https://localhost:9200/graph/v1.0/users/%user_id%','https://localhost:9200/graph/v1.0/users/%user_id%']} |
|
||||
| {'members@odata.bind': ['https://localhost:9200/graph/v1.0/users/%user_id%'.'https://localhost:9200/graph/v1.0/users/%user_id%']} |
|
||||
|
||||
@issue-5871
|
||||
Scenario: admin tries to add multiple users with wrong host
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When user "Alice" tries to add the following users to a group "grp1" at once with an invalid host using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
@issue-5871
|
||||
Scenario: admin tries to add single user with wrong host
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When user "Alice" tries to add user "Brian" to group "grp1" with an invalid host using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
|
||||
Scenario Outline: try to add invalid user id to a group
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" tries to add an invalid user id "<invalid-uuidv4>" to a group "grp1" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| invalid-uuidv4 | comment |
|
||||
| �ϰ�Ϧ-@$@^-¶Ëøœ-ɧɸɱʨΌϖЁϿ | UTF characters |
|
||||
| b1f74ec4-dd7e-11ef-a543-03775734d0f71 | adding an extra character at end of valid UUID pattern |
|
||||
| 4c510adac8-6b-4815-882042cdf-82c3d51 | invalid UUID pattern |
|
||||
|
||||
|
||||
Scenario Outline: try to add invalid user ids to a group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" tries to add the following invalid user ids to a group "grp1" at once using the Graph API
|
||||
| user-id |
|
||||
| <invalid-uuidv4> |
|
||||
| <invalid-uuidv4> |
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| invalid-uuidv4 | comment |
|
||||
| �ϰ�Ϧ-@$@^-¶Ëøœ-ɧɸɱʨΌϖЁϿ | UTF characters |
|
||||
| b1f74ec4-dd7e-11ef-a543-03775734d0f71 | adding an extra character at end of valid UUID pattern |
|
||||
| 4c510adac8-6b-4815-882042cdf-82c3d51 | invalid UUID pattern |
|
||||
|
||||
@issue-5855
|
||||
Scenario: add same user twice to a group at once
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And user "Alice" has created a group "grp1" using the Graph API
|
||||
When the administrator "Alice" adds the following users to a group "grp1" at once using the Graph API
|
||||
| username |
|
||||
| Brian |
|
||||
| Brian |
|
||||
Then the HTTP status code should be "204"
|
||||
And the user "Brian" should be listed once in the group "grp1"
|
||||
@@ -0,0 +1,20 @@
|
||||
Feature: an user changes its own password
|
||||
As a user
|
||||
I want to change my password
|
||||
So that I can use new combination as password
|
||||
|
||||
|
||||
Scenario Outline: change own password
|
||||
Given user "Alice" has been created with default attributes
|
||||
When the user "Alice" changes its own password "<current-password>" to "<new-password>" using the Graph API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
Examples:
|
||||
| current-password | new-password | http-status-code |
|
||||
| 123456 | validPass | 204 |
|
||||
| 123456 | кириллица | 204 |
|
||||
| 123456 | 密码 | 204 |
|
||||
| 123456 | ?&^%0 | 204 |
|
||||
| 123456 | | 400 |
|
||||
| 123456 | 123456 | 400 |
|
||||
| wrongPass | 123456 | 400 |
|
||||
| | validPass | 400 |
|
||||
@@ -0,0 +1,49 @@
|
||||
Feature: create group
|
||||
As an admin
|
||||
I want to create a group
|
||||
So that I can add users to the group
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
|
||||
|
||||
Scenario Outline: admin user creates a group
|
||||
When user "Alice" creates a group "<group>" using the Graph API
|
||||
Then the HTTP status code should be "201"
|
||||
And group "<group>" should exist
|
||||
Examples:
|
||||
| group |
|
||||
| simplegroup |
|
||||
| España§àôœ€ |
|
||||
| नेपाली |
|
||||
| $x<=>[y*z^2+1]! |
|
||||
| 😅 😆 |
|
||||
| comma,grp1 |
|
||||
| Finance (NP) |
|
||||
| slash\Middle |
|
||||
|
||||
@issue-3516
|
||||
Scenario: admin user tries to create a group that already exists
|
||||
Given group "mygroup" has been created
|
||||
When user "Alice" tries to create a group "mygroup" using the Graph API
|
||||
Then the HTTP status code should be "409"
|
||||
And group "mygroup" should exist
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin can't create a group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When user "Brian" tries to create a group "mygroup" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And group "mygroup" should not exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-5050
|
||||
Scenario: admin user tries to create a group that is the empty string
|
||||
When user "Alice" tries to create a group "" using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
@@ -0,0 +1,24 @@
|
||||
Feature: create groups, group names are case insensitive
|
||||
As an admin
|
||||
I want to create groups with similar cases
|
||||
So that I can check if the group names are case sensitive
|
||||
|
||||
@issue-3516
|
||||
Scenario Outline: group names are case insensitive, creating groups with different upper and lower case names
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And group "<group>" has been created
|
||||
When the administrator creates a group "<group-2>" using the Graph API
|
||||
And the administrator creates a group "<group-3>" using the Graph API
|
||||
Then the HTTP status code of responses on all endpoints should be "409"
|
||||
And these groups should not exist:
|
||||
| groupname |
|
||||
| <group-2> |
|
||||
| <group-3> |
|
||||
Examples:
|
||||
| ocs-api-version | group | group-2 | group-3 |
|
||||
| 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
|
||||
| 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
|
||||
| 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
|
||||
| 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
|
||||
| 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
|
||||
| 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
|
||||
@@ -0,0 +1,146 @@
|
||||
Feature: create user
|
||||
As a admin
|
||||
I want to create a user
|
||||
So that the user can use the application
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
@issue-3516
|
||||
Scenario Outline: admin creates a user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | <user> |
|
||||
| displayName | <display-name> |
|
||||
| email | <email> |
|
||||
| password | <password> |
|
||||
| accountEnabled | <enable> |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And user "<user>" <should-or-not> exist
|
||||
Examples:
|
||||
| user | display-name | email | password | http-status-code | enable | should-or-not |
|
||||
| SameDisplayName | Alice Hansen | new@example.org | containsCharacters(*:!;_+-&) | 201 | true | should |
|
||||
| withoutPassSameEmail | without pass | alice@example.org | | 201 | true | should |
|
||||
| name | pass with space | example@example.org | my pass | 201 | true | should |
|
||||
| user1 | user names must not start with a number | example@example.org | my pass | 201 | true | should |
|
||||
| nameWithCharacters(*:!;_+-&) | user | new@example.org | 123 | 400 | true | should not |
|
||||
| name with space | name with space | example@example.org | 123 | 400 | true | should not |
|
||||
| createDisabledUser | disabled user | example@example.org | 123 | 201 | false | should |
|
||||
| nameWithNumbers0123456 | user | name0123456@example.org | 123 | 201 | true | should |
|
||||
| name.with.dots | user | name.w.dots@example.org | 123 | 201 | true | should |
|
||||
| 123456789 | user | 123456789@example.org | 123 | 400 | true | should not |
|
||||
| 0.0 | user | float@example.org | 123 | 400 | true | should not |
|
||||
| withoutEmail | without email | | 123 | 201 | true | should |
|
||||
| Alice | same userName | new@example.org | 123 | 409 | true | should |
|
||||
|
||||
|
||||
Scenario: user cannot be created with empty name
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | |
|
||||
| displayName | emptyName |
|
||||
| email | @example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
|
||||
Scenario Outline: user without admin right cannot create a user
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | user |
|
||||
| displayName | user |
|
||||
| email | @example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "403"
|
||||
And user "user" should not exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: user cannot be created with the name of the disabled user
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the user "Alice" has disabled user "Brian"
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | Brian |
|
||||
| displayName | This is another Brian |
|
||||
| email | brian@example.com |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "409"
|
||||
|
||||
|
||||
Scenario: user can be created with the name of the deleted user
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the user "Alice" has deleted a user "Brian"
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | Brian |
|
||||
| displayName | This is another Brian |
|
||||
| email | brian@example.com |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "201"
|
||||
And user "Brian" should exist
|
||||
|
||||
@env-config
|
||||
Scenario Outline: create user with setting КуСфера no restriction on the user name
|
||||
Given the config "GRAPH_USERNAME_MATCH" has been set to "none"
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" creates a new user with the following attributes using the Graph API:
|
||||
| userName | <user> |
|
||||
| displayName | test user |
|
||||
| email | new@example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "201"
|
||||
And user "<user>" should exist
|
||||
Examples:
|
||||
| user | description |
|
||||
| 1248Bob | user names starts with the number |
|
||||
| (*:!;+-&$%)_alice | user names starts with the ASCII characters |
|
||||
|
||||
@env-config
|
||||
Scenario: create user with setting КуСфера not to assign the default user role
|
||||
Given the config "GRAPH_ASSIGN_DEFAULT_USER_ROLE" has been set to "false"
|
||||
When the user "admin" creates a new user with the following attributes using the Graph API:
|
||||
| userName | sam |
|
||||
| displayName | test user |
|
||||
| email | new@example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "201"
|
||||
And user "sam" should exist
|
||||
When the administrator retrieves the assigned role of user "sam" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the Graph API response should have no role
|
||||
|
||||
@env-config
|
||||
Scenario: create user with setting КуСфера assign the default user role
|
||||
Given the config "GRAPH_ASSIGN_DEFAULT_USER_ROLE" has been set to "true"
|
||||
When the user "admin" creates a new user with the following attributes using the Graph API:
|
||||
| userName | sam |
|
||||
| displayName | test user |
|
||||
| email | new@example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "201"
|
||||
And user "sam" should exist
|
||||
And user "sam" should have the role "User" assigned
|
||||
|
||||
|
||||
Scenario: user is created with the default User role
|
||||
When the user "admin" creates a new user with the following attributes using the Graph API:
|
||||
| userName | sam |
|
||||
| displayName | test user |
|
||||
| email | new@example.org |
|
||||
| password | 123 |
|
||||
| accountEnabled | true |
|
||||
Then the HTTP status code should be "201"
|
||||
And user "sam" should exist
|
||||
And user "sam" should have the role "User" assigned
|
||||
@@ -0,0 +1,119 @@
|
||||
Feature: delete groups
|
||||
As an admin
|
||||
I want to be able to delete groups
|
||||
So that I can remove unnecessary groups
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
|
||||
|
||||
Scenario Outline: admin user deletes a group
|
||||
Given group "<group>" has been created
|
||||
When user "Alice" deletes group "<group>" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And group "<group>" should not exist
|
||||
Examples:
|
||||
| group | comment |
|
||||
| simplegroup | nothing special here |
|
||||
| España§àôœ€ | special European and other characters |
|
||||
| नेपाली | Unicode group name |
|
||||
| brand-new-group | dash |
|
||||
| the.group | dot |
|
||||
| left,right | comma |
|
||||
| 0 | The "false" group |
|
||||
| Finance (NP) | Space and brackets |
|
||||
| Admin&Finance | Ampersand |
|
||||
| admin:Pokhara@Nepal | Colon and @ |
|
||||
| maint+eng | Plus sign |
|
||||
| $x<=>[y*z^2]! | Maths symbols |
|
||||
| Mgmt\Middle | Backslash |
|
||||
| 😁 😂 | emoji |
|
||||
| maintenance#123 | Hash sign |
|
||||
| 50%25=0 | %25 literal looks like an escaped "%" |
|
||||
| staff?group | Question mark |
|
||||
| Mgmt/Sydney | Slash (special escaping happens) |
|
||||
| Mgmt//NSW/Sydney | Multiple slash |
|
||||
| priv/subadmins/1 | Subadmins mentioned not at the end |
|
||||
| var/../etc | using slash-dot-dot |
|
||||
|
||||
@issue-5083
|
||||
Scenario Outline: admin user deletes a group having % (as only special char) in its name
|
||||
Given group "<group>" has been created
|
||||
When user "Alice" deletes group "<group>" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And group "<group>" should not exist
|
||||
Examples:
|
||||
| group | comment |
|
||||
| 50%pass | Percent sign (special escaping happens) |
|
||||
| 50%2Eagle | %2E literal looks like an escaped "." |
|
||||
| 50%2Fix | %2F literal looks like an escaped slash |
|
||||
|
||||
|
||||
Scenario: admin user tries to delete nonexistent group
|
||||
When user "Alice" tries to delete group "nonexistent" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin can't delete a group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "new-group" has been created
|
||||
When user "Brian" tries to delete group "new-group" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And group "new-group" should exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to delete nonexistent group
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" tries to delete group "nonexistent" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-903
|
||||
Scenario: deleted group should not be listed in the sharees list
|
||||
Given group "grp1" has been created
|
||||
And group "grp2" has been created
|
||||
And user "Alice" has uploaded file with content "sample text" to "lorem.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | lorem.txt |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | lorem.txt |
|
||||
| space | Personal |
|
||||
| sharee | grp2 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
And group "grp1" has been deleted
|
||||
When user "Alice" gets all the shares of the file "lorem.txt" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And group "grp2" should be included in the response
|
||||
But group "grp1" should not be included in the response
|
||||
|
||||
|
||||
Scenario: user should not see share received via deleted group
|
||||
Given user "Alice" has uploaded file with content "sample text" to "lorem.txt"
|
||||
And user "Brian" has been created with default attributes
|
||||
And group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | lorem.txt |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
When user "Alice" deletes group "grp1" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And user "Brian" should not have any received shares
|
||||
@@ -0,0 +1,165 @@
|
||||
Feature: delete user
|
||||
As an admin
|
||||
I want to be able to delete users
|
||||
So that I can remove unnecessary users
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
|
||||
Scenario Outline: admin user deletes a user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | <user-name> |
|
||||
| displayName | <display-name> |
|
||||
| email | <email> |
|
||||
| password | <password> |
|
||||
When the user "Alice" deletes a user "<user-name>" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And user "<user-name>" should not exist
|
||||
Examples:
|
||||
| user-name | display-name | email | password |
|
||||
| SameDisplayName | Alice Hansen | new@example.org | containsCharacters(*:!;_+-&) |
|
||||
| withoutPassSameEmail | without pass | alice@example.org | |
|
||||
| name | pass with space | example@example.org | my pass |
|
||||
|
||||
|
||||
Scenario: delete a user and specify the user name in different case
|
||||
Given user "brand-new-user" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" deletes a user "Brand-New-User" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And user "brand-new-user" should not exist
|
||||
|
||||
|
||||
Scenario Outline: admin user deletes another user with different role
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Alice" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And user "Brian" should not exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user tries to delete his/her own account
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" deletes a user "Alice" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And user "Alice" should exist
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to delete his/her own account
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When the user "Alice" deletes a user "Alice" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And user "Alice" should exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user tries to delete a nonexistent user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When the user "Alice" tries to delete a nonexistent user using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to delete a nonexistent user
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When the user "Alice" tries to delete a nonexistent user using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to delete another user with different role
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role-2>" to user "Brian" using the Graph API
|
||||
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When the user "Alice" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And user "Brian" should exist
|
||||
Examples:
|
||||
| user-role | user-role-2 |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| Space Admin | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
| User Light | Admin |
|
||||
|
||||
|
||||
Scenario: admin user deletes a disabled user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Brian" has been created with default attributes
|
||||
And the user "Alice" has disabled user "Brian"
|
||||
When the user "Alice" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And user "Brian" should not exist
|
||||
|
||||
|
||||
Scenario Outline: normal user tries to delete a disabled user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Carol" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role-2>" to user "Brian" using the Graph API
|
||||
And the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
|
||||
And the user "Alice" has disabled user "Brian"
|
||||
When the user "Carol" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And user "Brian" should exist
|
||||
Examples:
|
||||
| user-role | user-role-2 |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| Space Admin | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
| User Light | Admin |
|
||||
|
||||
|
||||
Scenario: personal space is deleted automatically when the user is deleted
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Brian" has been created with default attributes
|
||||
When the user "Alice" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
When user "Alice" lists all spaces via the Graph API with query "$filter=driveType eq 'personal'"
|
||||
Then the json response should not contain a space with name "Brian Murphy"
|
||||
|
||||
|
||||
Scenario: accepted share is deleted automatically when the user is deleted
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Brian" has created folder "new"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | new |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
When the user "Alice" deletes a user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And as "Alice" folder "Shares/new" should not exist
|
||||
@@ -0,0 +1,54 @@
|
||||
Feature: edit group name
|
||||
As an admin
|
||||
I want to be able to edit group name
|
||||
So that I can manage group name
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
|
||||
@issue-5977
|
||||
Scenario Outline: admin user renames a group
|
||||
Given group "<group>" has been created
|
||||
When user "Alice" renames group "<group>" to "<new-group>" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And group "<group>" should not exist
|
||||
And group "<new-group>" should exist
|
||||
Examples:
|
||||
| group | new-group |
|
||||
| grp1 | grp101 |
|
||||
| grp1 | España§àôœ€ |
|
||||
| grp1 | नेपाली |
|
||||
| grp1 | $x<=>[y*z^2]! |
|
||||
| grp1 | staff?group |
|
||||
| grp1 | 50%pass |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin can't rename a group
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
And group "grp1" has been created
|
||||
When user "Alice" tries to rename group "grp1" to "grp101" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user tries to rename nonexistent group
|
||||
When user "Alice" tries to rename a nonexistent group to "grp1" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
And group "grp1" should not exist
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to rename nonexistent group
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" tries to rename a nonexistent group to "grp1" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And group "grp1" should not exist
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
@@ -0,0 +1,400 @@
|
||||
Feature: edit user
|
||||
As an admin
|
||||
I want to be able to edit user information
|
||||
So that I can manage users
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | Brian |
|
||||
| displayName | Brian Murphy |
|
||||
| email | brian@example.com |
|
||||
| password | 1234 |
|
||||
|
||||
@issue-7044
|
||||
Scenario Outline: admin user can edit another user's name
|
||||
Given user "Carol" has been created with default attributes
|
||||
When the user "Alice" changes the user name of user "Carol" to "<user>" using the Graph API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the user information of "<new-user>" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"onPremisesSamAccountName": {
|
||||
"enum": ["<new-user>"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| action description | user | http-status-code | new-user |
|
||||
| change to a valid user name | Lionel | 200 | Lionel |
|
||||
| user name characters | a*!_+-& | 200 | a*!_+-& |
|
||||
| change to existing user name | Brian | 409 | Carol |
|
||||
| empty user name | | 400 | Carol |
|
||||
|
||||
|
||||
Scenario: admin user changes the name of a user to the name of an existing disabled user
|
||||
Given the user "Alice" has created a new user with the following attributes:
|
||||
| userName | sam |
|
||||
| displayName | sam |
|
||||
| email | sam@example.com |
|
||||
| password | 1234 |
|
||||
And the user "Alice" has disabled user "Brian"
|
||||
When the user "Alice" changes the user name of user "sam" to "Brian" using the Graph API
|
||||
Then the HTTP status code should be "409"
|
||||
And the user information of "sam" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["sam"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: admin user changes the name of a user to the name of a previously deleted user
|
||||
Given the user "Alice" has created a new user with the following attributes:
|
||||
| userName | sam |
|
||||
| displayName | sam |
|
||||
| email | sam@example.com |
|
||||
| password | 1234 |
|
||||
And the user "Alice" has deleted a user "sam"
|
||||
When the user "Alice" changes the user name of user "Brian" to "sam" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the user information of "Brian" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["sam"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: admin user can edit another user display name
|
||||
When the user "Alice" changes the display name of user "Brian" to "<new-display-name>" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the user information of "Brian" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["<expected-display-name>"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| action description | new-display-name | expected-display-name |
|
||||
| change to a display name | Olaf Scholz | Olaf Scholz |
|
||||
| override to existing display name | Carol King | Carol King |
|
||||
| change to an empty display name | | Brian Murphy |
|
||||
| displayName with characters | *:!;_+-&#(?) | *:!;_+-&#(?) |
|
||||
|
||||
|
||||
Scenario: admin user tries to edit nonexistent user's name
|
||||
When the user "Alice" tries to change the user name of user "nonexistent" to "newusername" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to edit nonexistent user's name
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When the user "Alice" tries to change the user name of user "nonexistent" to "newusername" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to change his/her own display name
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Brian" tries to change the display name of user "Brian" to "Brian Murphy" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the user information of "Alice" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to edit another user's display name
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | Carol |
|
||||
| displayName | Carol King |
|
||||
| email | carol@example.com |
|
||||
| password | 1234 |
|
||||
And the administrator has assigned the role "<user-role-2>" to user "Carol" using the Graph API
|
||||
When the user "Brian" tries to change the display name of user "Carol" to "Alice Hansen" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the user information of "Carol" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol King"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role | user-role-2 |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| Space Admin | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
| User Light | Admin |
|
||||
|
||||
|
||||
Scenario: admin user resets password of another user
|
||||
Given user "Brian" has uploaded file with content "test file for reset password" to "/resetpassword.txt"
|
||||
When the user "Alice" resets the password of user "Brian" to "newpassword" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the content of file "resetpassword.txt" for user "Brian" using password "newpassword" should be "test file for reset password"
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to reset the password of another user
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | Carol |
|
||||
| displayName | Carol King |
|
||||
| email | carol@example.com |
|
||||
| password | 1234 |
|
||||
And the administrator has assigned the role "<user-role-2>" to user "Carol" using the Graph API
|
||||
And user "Carol" has uploaded file with content "test file for reset password" to "/resetpassword.txt"
|
||||
When the user "Brian" resets the password of user "Carol" to "newpassword" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the content of file "resetpassword.txt" for user "Carol" using password "1234" should be "test file for reset password"
|
||||
And user "Carol" should not be able to log in with wrong password "newpassword"
|
||||
Examples:
|
||||
| user-role | user-role-2 |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| Space Admin | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
| User Light | Admin |
|
||||
|
||||
|
||||
Scenario: admin user disables another user
|
||||
When the user "Alice" disables user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" gets information of user "Brian" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"accountEnabled"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian Murphy"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian"]
|
||||
},
|
||||
"accountEnabled": {
|
||||
"type": "boolean",
|
||||
"enum": [false]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to disable another user
|
||||
Given user "Carol" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Brian" tries to disable user "Carol" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
When user "Alice" gets information of user "Carol" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"accountEnabled"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol King"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol"]
|
||||
},
|
||||
"accountEnabled": {
|
||||
"type": "boolean",
|
||||
"enum": [true]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user enables disabled user
|
||||
Given the user "Alice" has disabled user "Brian"
|
||||
When the user "Alice" enables user "Brian" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" gets information of user "Brian" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"accountEnabled"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian Murphy"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian"]
|
||||
},
|
||||
"accountEnabled": {
|
||||
"type": "boolean",
|
||||
"enum": [true]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to enable another user
|
||||
Given user "Carol" has been created with default attributes
|
||||
And the user "Alice" has disabled user "Carol"
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Brian" tries to enable user "Carol" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
When user "Alice" gets information of user "Carol" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"accountEnabled"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol King"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol"]
|
||||
},
|
||||
"accountEnabled": {
|
||||
"type": "boolean",
|
||||
"enum": [false]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
@@ -0,0 +1,673 @@
|
||||
Feature: get groups and their members
|
||||
As an admin
|
||||
I want to be able to get groups
|
||||
So that I can see all the groups and their members
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
|
||||
|
||||
Scenario: admin user lists all the groups
|
||||
Given group "tea-lover" has been created
|
||||
And group "coffee-lover" has been created
|
||||
And group "h2o-lover" has been created
|
||||
When user "Alice" gets all the groups using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the extra groups returned by the API should be
|
||||
| tea-lover |
|
||||
| coffee-lover |
|
||||
| h2o-lover |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin shouldn't get the groups list
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "tea-lover" has been created
|
||||
And group "coffee-lover" has been created
|
||||
And group "h2o-lover" has been created
|
||||
When user "Brian" gets all the groups using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["search term too short"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user gets users of a group
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "tea-lover" has been created
|
||||
And user "Brian" has been added to group "tea-lover"
|
||||
And user "Carol" has been added to group "tea-lover"
|
||||
When user "Alice" gets all the members of group "tea-lover" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the users returned by the API should be
|
||||
| Brian |
|
||||
| Carol |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin shouldn't get users of a group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "tea-lover" has been created
|
||||
When user "Brian" gets all the members of group "tea-lover" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user gets all groups along with its member's information
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "tea-lover" has been created
|
||||
And group "coffee-lover" has been created
|
||||
And user "Alice" has been added to group "tea-lover"
|
||||
And user "Brian" has been added to group "coffee-lover"
|
||||
And user "Carol" has been added to group "tea-lover"
|
||||
When user "Alice" retrieves all groups along with their members using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should contain the group "coffee-lover" in the item 'value', the group-details should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"members"
|
||||
],
|
||||
"properties": {
|
||||
"members": {
|
||||
"type": "array",
|
||||
"maxItems": 1,
|
||||
"minItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian Murphy"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["brian@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And the JSON data of the response should contain the group "tea-lover" in the item 'value', the group-details should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"members"
|
||||
],
|
||||
"properties": {
|
||||
"members": {
|
||||
"type": "array",
|
||||
"maxItems": 2,
|
||||
"minItems": 2,
|
||||
"uniqueItems": true,
|
||||
"items": {
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["alice@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice"]
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol King"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["carol@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Carol"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin shouldn't get all groups along with its member's information
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "tea-lover" has been created
|
||||
And group "coffee-lover" has been created
|
||||
And user "Alice" has been added to group "tea-lover"
|
||||
And user "Brian" has been added to group "coffee-lover"
|
||||
When user "Brian" retrieves all groups along with their members using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["search term too short"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user gets a group along with its member's information
|
||||
Given user "Brian" has been created with default attributes
|
||||
And group "tea-lover" has been created
|
||||
And user "Alice" has been added to group "tea-lover"
|
||||
And user "Brian" has been added to group "tea-lover"
|
||||
When user "Alice" gets all the members information of group "tea-lover" using the Graph API
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"members"
|
||||
],
|
||||
"properties": {
|
||||
"members": {
|
||||
"type": "array",
|
||||
"maxItems": 2,
|
||||
"minItems": 2,
|
||||
"uniqueItems": true,
|
||||
"items": {
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["alice@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice"]
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian Murphy"]
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["brian@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Brian"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
@issue-5604
|
||||
Scenario Outline: user other than the admin gets a group along with its member's information
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "tea-lover" has been created
|
||||
And user "Alice" has been added to group "tea-lover"
|
||||
And user "Brian" has been added to group "tea-lover"
|
||||
When user "Brian" gets all the members information of group "tea-lover" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin user gets details of a group
|
||||
Given group "tea-lover" has been created
|
||||
When user "Alice" gets details of the group "tea-lover" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["tea-lover"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%group_id_pattern%$"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
@issue-5604
|
||||
Scenario Outline: non-admin user tries to get details of a group
|
||||
Given group "tea-lover" has been created
|
||||
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" gets details of the group "tea-lover" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: get details of group with UTF-8 characters name
|
||||
Given group "<group>" has been created
|
||||
When user "Alice" gets details of the group "<group>" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["<group>"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%group_id_pattern%$"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| group |
|
||||
| España§àôœ€ |
|
||||
| नेपाली |
|
||||
| $x<=>[y*z^2+1]! |
|
||||
| եòɴԪ˯ΗՐΛɔπ |
|
||||
|
||||
|
||||
Scenario: admin user tries to get group information of non-existing group
|
||||
When user "Alice" gets details of the group "non-existing" using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
@issue-5604
|
||||
Scenario Outline: non-admin user tries to get group information of non-existing group
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" gets details of the group "non-existing" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: non-admin user searches for a group by group name
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And group "tea-lover" has been created
|
||||
When user "Brian" searches for group "<group>" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"value"
|
||||
],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"maxItems": 1,
|
||||
"minItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"groupTypes"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["tea-lover"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "%group_id_pattern%"
|
||||
},
|
||||
"groupTypes": {
|
||||
"const": []
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| group |
|
||||
| tea |
|
||||
| %22tea-%22 |
|
||||
|
||||
|
||||
Scenario: non-admin user tries to search for a group by group name with less than 3 characters
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And group "tea-lover" has been created
|
||||
When user "Brian" tries to search for group "te" using Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message":{
|
||||
"type": "string",
|
||||
"enum": ["search term too short"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
@issue-7990
|
||||
Scenario Outline: user tries to search for groups with invalid characters/token (search term without quotation)
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And group "<group>" has been created
|
||||
When user "Brian" tries to search for group "<group>" using Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Token '<token>' is invalid"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| group | token |
|
||||
| tea-lovers | -lovers |
|
||||
| tea@lovers | @lovers |
|
||||
|
||||
@issue-7990
|
||||
Scenario Outline: user searches for groups with special characters (search term with quotation)
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Brian |
|
||||
And group "<group>" has been created
|
||||
When user "Brian" tries to search for group '"<group>"' using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["value"],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"maxItems": 1,
|
||||
"minItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": ["displayName", "id", "groupTypes"],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "<group>"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "%group_id_pattern%"
|
||||
},
|
||||
"groupTypes": {
|
||||
"const": []
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| group | token |
|
||||
| tea-lovers | -lovers |
|
||||
| tea@lovers | @lovers |
|
||||
| -_.ocgrp | -_. |
|
||||
| _ocgrp@ | _oc |
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,105 @@
|
||||
Feature: get user's own information
|
||||
As user
|
||||
I want to be able to retrieve my own information
|
||||
So that I can see my information
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
|
||||
Scenario: user gets his/her own information with no group involvement
|
||||
When the user "Alice" retrieves her information using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["alice@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: user gets his/her own information with group involvement
|
||||
Given group "tea-lover" has been created
|
||||
And group "coffee-lover" has been created
|
||||
And user "Alice" has been added to group "tea-lover"
|
||||
And user "Alice" has been added to group "coffee-lover"
|
||||
When the user "Alice" retrieves her information using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName"
|
||||
],
|
||||
"properties": {
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"type": "string",
|
||||
"enum": ["alice@example.org"]
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"type": "string",
|
||||
"enum": ["Alice"]
|
||||
},
|
||||
"memberOf": {
|
||||
"type": "array",
|
||||
"minItems": 2,
|
||||
"maxItems": 2,
|
||||
"uniqueItems": true,
|
||||
"items": {
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["tea-lover"]
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"type": "string",
|
||||
"enum": ["coffee-lover"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
@@ -0,0 +1,224 @@
|
||||
Feature: remove a user from a group
|
||||
As an admin
|
||||
I want to be able to remove a user from a group
|
||||
So that I can manage user access to group resources
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
|
||||
Scenario: admin removes a user from a group
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| brand-new-group | nothing special here |
|
||||
| España§àôœ€ | special European and other characters |
|
||||
| नेपाली | Unicode group name |
|
||||
And the following users have been added to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | España§àôœ€ |
|
||||
| Alice | नेपाली |
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | España§àôœ€ |
|
||||
| Alice | नेपाली |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should not belong to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | España§àôœ€ |
|
||||
| Alice | नेपाली |
|
||||
|
||||
|
||||
Scenario: admin removes a user from a group with special characters
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| brand-new-group | dash |
|
||||
| the.group | dot |
|
||||
| left,right | comma |
|
||||
| 0 | The "false" group |
|
||||
| Finance (NP) | Space and brackets |
|
||||
| Admin&Finance | Ampersand |
|
||||
| admin:Pokhara@Nepal | Colon and @ |
|
||||
| maint+eng | Plus sign |
|
||||
| $x<=>[y*z^2]! | Maths symbols |
|
||||
| Mgmt\Middle | Backslash |
|
||||
| 😁 😂 | emoji |
|
||||
And the following users have been added to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | the.group |
|
||||
| Alice | left,right |
|
||||
| Alice | 0 |
|
||||
| Alice | Finance (NP) |
|
||||
| Alice | Admin&Finance |
|
||||
| Alice | admin:Pokhara@Nepal |
|
||||
| Alice | maint+eng |
|
||||
| Alice | $x<=>[y*z^2]! |
|
||||
| Alice | Mgmt\Middle |
|
||||
| Alice | 😁 😂 |
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | the.group |
|
||||
| Alice | left,right |
|
||||
| Alice | 0 |
|
||||
| Alice | Finance (NP) |
|
||||
| Alice | Admin&Finance |
|
||||
| Alice | admin:Pokhara@Nepal |
|
||||
| Alice | maint+eng |
|
||||
| Alice | $x<=>[y*z^2]! |
|
||||
| Alice | Mgmt\Middle |
|
||||
| Alice | 😁 😂 |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should not belong to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
| Alice | the.group |
|
||||
| Alice | left,right |
|
||||
| Alice | 0 |
|
||||
| Alice | Finance (NP) |
|
||||
| Alice | Admin&Finance |
|
||||
| Alice | admin:Pokhara@Nepal |
|
||||
| Alice | maint+eng |
|
||||
| Alice | $x<=>[y*z^2]! |
|
||||
| Alice | Mgmt\Middle |
|
||||
| Alice | 😁 😂 |
|
||||
|
||||
|
||||
Scenario: admin removes a user from a group having % and # in their names
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| maintenance#123 | Hash sign |
|
||||
| 50%25=0 | %25 literal looks like an escaped "%" |
|
||||
| staff?group | Question mark |
|
||||
| 50%pass | Percent sign (special escaping happens) |
|
||||
| 50%2Eagle | %2E literal looks like an escaped "." |
|
||||
| 50%2Fix | %2F literal looks like an escaped slash |
|
||||
And the following users have been added to the following groups
|
||||
| username | groupname |
|
||||
| Alice | maintenance#123 |
|
||||
| Alice | 50%25=0 |
|
||||
| Alice | staff?group |
|
||||
| Alice | 50%pass |
|
||||
| Alice | 50%2Eagle |
|
||||
| Alice | 50%2Fix |
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | maintenance#123 |
|
||||
| Alice | 50%25=0 |
|
||||
| Alice | staff?group |
|
||||
| Alice | 50%pass |
|
||||
| Alice | 50%2Eagle |
|
||||
| Alice | 50%2Fix |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should not belong to the following groups
|
||||
| username | groupname |
|
||||
| Alice | maintenance#123 |
|
||||
| Alice | 50%25=0 |
|
||||
| Alice | staff?group |
|
||||
| Alice | 50%pass |
|
||||
| Alice | 50%2Eagle |
|
||||
| Alice | 50%2Fix |
|
||||
|
||||
|
||||
Scenario: admin removes a user from a group that has forward-slash(s) in the group name
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| Mgmt/Sydney | Slash (special escaping happens) |
|
||||
| Mgmt//NSW/Sydney | Multiple slash |
|
||||
| priv/subadmins/1 | Subadmins mentioned not at the end |
|
||||
| var/../etc | using slash-dot-dot |
|
||||
And the following users have been added to the following groups
|
||||
| username | groupname |
|
||||
| Alice | Mgmt/Sydney |
|
||||
| Alice | Mgmt//NSW/Sydney |
|
||||
| Alice | priv/subadmins/1 |
|
||||
| Alice | var/../etc |
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | Mgmt/Sydney |
|
||||
| Alice | Mgmt//NSW/Sydney |
|
||||
| Alice | priv/subadmins/1 |
|
||||
| Alice | var/../etc |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should not belong to the following groups
|
||||
| username | groupname |
|
||||
| Alice | Mgmt/Sydney |
|
||||
| Alice | Mgmt//NSW/Sydney |
|
||||
| Alice | priv/subadmins/1 |
|
||||
| Alice | var/../etc |
|
||||
|
||||
|
||||
Scenario: admin tries to remove a user from a nonexistent group
|
||||
When the administrator tries to remove user "Alice" from a nonexistent group using the Graph API
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to remove a user from a nonexistent group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" tries to remove user "Brian" from a nonexistent group using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-5938
|
||||
Scenario Outline: user other than the admin can't remove a user from their group
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And group "grp1" has been created
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
When user "Alice" tries to remove user "Brian" from group "grp1" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"error"
|
||||
],
|
||||
"properties": {
|
||||
"error": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"message"
|
||||
],
|
||||
"properties": {
|
||||
"message": {
|
||||
"type": "string",
|
||||
"enum": ["Forbidden"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And user "Brian" should belong to group "grp1"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: admin removes a disabled user from a group
|
||||
Given these groups have been created:
|
||||
| groupname | comment |
|
||||
| brand-new-group | nothing special here |
|
||||
And the following users have been added to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
And the user "Admin" has disabled user "Alice"
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the following users should not belong to the following groups
|
||||
| username | groupname |
|
||||
| Alice | brand-new-group |
|
||||
@@ -0,0 +1,496 @@
|
||||
@env-config
|
||||
Feature: edit/search user including email
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | Brian |
|
||||
| displayName | Brian Murphy |
|
||||
| email | brian@example.com |
|
||||
| password | 1234 |
|
||||
And the config "OC_SHOW_USER_EMAIL_IN_RESULTS" has been set to "true"
|
||||
|
||||
|
||||
Scenario Outline: admin user can edit another user's email
|
||||
When the user "Alice" changes the email of user "Brian" to "<new-email>" using the Graph API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the user information of "Brian" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["mail"],
|
||||
"properties": {
|
||||
"mail": {
|
||||
"const": "<expected-email>"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| action description | new-email | http-status-code | expected-email |
|
||||
| change to a valid email | newemail@example.com | 200 | newemail@example.com |
|
||||
| override existing mail | brian@example.com | 200 | brian@example.com |
|
||||
| two users with same mail | alice@example.org | 200 | alice@example.org |
|
||||
| empty mail | | 400 | brian@example.com |
|
||||
| change to a invalid email | invalidEmail | 400 | brian@example.com |
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to change their email address
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Brian" tries to change the email of user "Brian" to "newemail@example.com" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the user information of "Brian" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["mail"],
|
||||
"properties": {
|
||||
"mail": {
|
||||
"const": "brian@example.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: normal user should not be able to edit another user's email
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And the user "Alice" has created a new user with the following attributes:
|
||||
| userName | Carol |
|
||||
| displayName | Carol King |
|
||||
| email | carol@example.com |
|
||||
| password | 1234 |
|
||||
And the administrator has assigned the role "<user-role-2>" to user "Carol" using the Graph API
|
||||
When the user "Brian" tries to change the email of user "Carol" to "newemail@example.com" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
And the user information of "Carol" should match this JSON schema
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["mail"],
|
||||
"properties": {
|
||||
"mail": {
|
||||
"const": "carol@example.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role | user-role-2 |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| Space Admin | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
| User Light | Admin |
|
||||
|
||||
|
||||
Scenario: admin user gets the information of a user
|
||||
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
|
||||
When user "Alice" gets information of user "Brian" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName",
|
||||
"accountEnabled",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Brian Murphy"
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"const": "brian@example.com"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "Brian"
|
||||
},
|
||||
"accountEnabled": {
|
||||
"const": true
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: user gets his/her own information along with drive information
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When the user "Brian" gets his drive information using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"onPremisesSamAccountName",
|
||||
"drive",
|
||||
"accountEnabled",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Brian Murphy"
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"const": "brian@example.com"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "Brian"
|
||||
},
|
||||
"accountEnabled": {
|
||||
"const": true
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
},
|
||||
"drive": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveAlias",
|
||||
"id",
|
||||
"name",
|
||||
"owner",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"driveType" : {
|
||||
"const": "personal"
|
||||
},
|
||||
"driveAlias" : {
|
||||
"const": "personal/brian"
|
||||
},
|
||||
"id" : {
|
||||
"type": "string",
|
||||
"pattern": "^%space_id_pattern%$"
|
||||
},
|
||||
"name": {
|
||||
"const": "Brian Murphy"
|
||||
},
|
||||
"owner": {
|
||||
"type": "object",
|
||||
"required": ["user"],
|
||||
"properties": {
|
||||
"user": {
|
||||
"type": "object",
|
||||
"required": ["id"],
|
||||
"properties": {
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "%user_id_pattern%"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": ["state"],
|
||||
"properties": {
|
||||
"state": {
|
||||
"const": "normal"
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": ["id", "webDavUrl"],
|
||||
"properties": {
|
||||
"state": {
|
||||
"const": "normal"
|
||||
},
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"pattern": "^%base_url%/dav/spaces/%space_id_pattern%$"
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"pattern": "^%base_url%/f/%space_id_pattern%$"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: non-admin user searches other users by display name
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When user "Brian" searches for user "ali" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["value"],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"mail",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Alice Hansen"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "Alice"
|
||||
},
|
||||
"mail": {
|
||||
"const": "alice@example.org"
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-7990
|
||||
Scenario: non-admin user searches other users by e-mail
|
||||
When user "Brian" searches for user "%22alice@example.org%22" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["value"],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Alice Hansen"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"mail": {
|
||||
"const": "alice@example.org"
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: non-admin user searches for a disabled users
|
||||
Given the user "Admin" has disabled user "Alice"
|
||||
When user "Brian" searches for user "alice" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["value"],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"mail",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Alice Hansen"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "Alice"
|
||||
},
|
||||
"mail": {
|
||||
"const": "alice@example.org"
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: non-admin user searches for multiple users having same displayname
|
||||
Given the user "Admin" has created a new user with the following attributes:
|
||||
| userName | another-alice |
|
||||
| displayName | Alice Murphy |
|
||||
| email | another-alice@example.org |
|
||||
| password | containsCharacters(*:!;_+-&) |
|
||||
When user "Brian" searches for user "alice" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": ["value"],
|
||||
"properties": {
|
||||
"value": {
|
||||
"type": "array",
|
||||
"minItems": 2,
|
||||
"maxItems": 2,
|
||||
"uniqueItems": true,
|
||||
"items": {
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"onPremisesSamAccountName",
|
||||
"mail",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Alice Hansen"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "Alice"
|
||||
},
|
||||
"mail": {
|
||||
"const": "alice@example.org"
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"displayName",
|
||||
"id",
|
||||
"mail",
|
||||
"userType"
|
||||
],
|
||||
"properties": {
|
||||
"displayName": {
|
||||
"const": "Alice Murphy"
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"pattern": "^%user_id_pattern%$"
|
||||
},
|
||||
"onPremisesSamAccountName": {
|
||||
"const": "another-alice"
|
||||
},
|
||||
"mail": {
|
||||
"const": "another-alice@example.org"
|
||||
},
|
||||
"userType": {
|
||||
"const": "Member"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: search other users when OC_SHOW_USER_EMAIL_IN_RESULTS config is disabled
|
||||
Given the config "OC_SHOW_USER_EMAIL_IN_RESULTS" has been set to "false"
|
||||
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" searches for user "Brian" using Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the search response should not contain user email
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
Reference in New Issue
Block a user