From a3b44b7be3a7d7fa73af36553c58bffed0ba29fb Mon Sep 17 00:00:00 2001 From: Prarup Gurung Date: Mon, 28 Feb 2022 16:54:28 +0545 Subject: [PATCH] Improved checks in tests for apiProvisioning-v1 suite --- .../apiProvisioning-v1/addUser.feature | 3 + .../apiProvisioningUsingAppPassword.feature | 9 ++- .../apiProvisioning-v1/deleteUser.feature | 4 + .../apiProvisioning-v1/editUser.feature | 81 +++++++++++++------ .../apiProvisioning-v1/enableUser.feature | 4 +- .../apiProvisioning-v1/getSubAdmins.feature | 7 +- .../apiProvisioning-v1/getUser.feature | 42 +++------- .../apiProvisioning-v1/getUsers.feature | 7 +- .../resetUserPassword.feature | 4 +- 9 files changed, 93 insertions(+), 68 deletions(-) diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature index 0671e9b2d7b6..89369959793e 100644 --- a/tests/acceptance/features/apiProvisioning-v1/addUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/addUser.feature @@ -155,6 +155,7 @@ Feature: add user | 123 | | -123 | | 0.0 | + @notToImplementOnOCIS Scenario: subadmin should not be able to create a new user Given user "brand-new-user" has been deleted @@ -174,6 +175,7 @@ Feature: add user Then the OCS status code should be "997" And the HTTP status code should be "401" And user "brand-new-user" should not exist + @notToImplementOnOCIS Scenario: subadmin should be able to create a new user into their group Given user "brand-new-user" has been deleted @@ -185,6 +187,7 @@ Feature: add user Then the OCS status code should be "100" And the HTTP status code should be "200" And user "brand-new-user" should exist + @notToImplementOnOCIS Scenario: subadmin should not be able to create a new user into other group Given user "brand-new-user" has been deleted diff --git a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature index 233faccf97c5..dcd4a0610962 100644 --- a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature +++ b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature @@ -31,9 +31,9 @@ Feature: access user provisioning API using app password And a new browser session for "brand-new-user" has been started And the user has generated a new app password named "my-client" When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password - Then the users returned by the API should be + Then the HTTP status code should be "200" + And the users returned by the API should be | another-new-user | - And the HTTP status code should be "200" @smokeTest Scenario: normal user gets their own information using the app password @@ -61,8 +61,9 @@ Feature: access user provisioning API using app password And a new browser session for "brand-new-user" has been started And the user has generated a new app password named "my-client" When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password - Then the users returned by the API should not include "another-new-user" - And the HTTP status code should be "200" + Then the HTTP status code should be "200" + And the users returned by the API should not include "another-new-user" + Scenario: normal user tries to get other user information using the app password Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature index 7bda8a1e6e5a..d6d3b0adb7e4 100644 --- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature @@ -72,6 +72,7 @@ Feature: delete users Then the OCS status code should be "100" And the HTTP status code should be "200" And user "another-admin" should not exist + @notToImplementOnOCIS Scenario: subadmin deletes a user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: @@ -86,6 +87,7 @@ Feature: delete users Then the OCS status code should be "100" And the HTTP status code should be "200" And user "another-subadmin" should not exist + @notToImplementOnOCIS Scenario: subadmin should not be able to delete another subadmin of same group Given these users have been created with default attributes and without skeleton files: @@ -99,6 +101,7 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-subadmin" should exist + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user with admin permissions in their group Given these users have been created with default attributes and without skeleton files: @@ -113,6 +116,7 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-admin" should exist + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user not in their group Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature index c6d54e0b298f..70c5c1ed03a4 100644 --- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature @@ -65,8 +65,6 @@ Feature: edit users Scenario: the administrator can override an existing user email Given user "brand-new-user" has been created with default attributes and without skeleton files And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" - And the OCS status code should be "100" - And the HTTP status code should be "200" When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" @@ -76,8 +74,6 @@ Feature: edit users Scenario: the administrator can clear an existing user email Given user "brand-new-user" has been created with default attributes and without skeleton files And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" - And the OCS status code should be "100" - And the HTTP status code should be "200" When the administrator changes the email of user "brand-new-user" to "" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" @@ -93,11 +89,17 @@ Feature: edit users And user "brand-new-user" has been added to group "new-group" And user "subadmin" has been made a subadmin of group "new-group" When user "subadmin" changes the quota of user "brand-new-user" to "12MB" using the provisioning API - And user "subadmin" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API - And user "subadmin" changes the display of user "brand-new-user" to "Anne Brown" using the provisioning API - Then the display name of user "brand-new-user" should be "Anne Brown" - And the email address of user "brand-new-user" should be "brand-new-user@example.com" + Then the OCS status code should be "100" + And the HTTP status code should be "200" And the quota definition of user "brand-new-user" should be "12 MB" + When user "subadmin" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + When user "subadmin" changes the display of user "brand-new-user" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "brand-new-user" should be "Anne Brown" Scenario: a normal user should be able to change their email address @@ -140,11 +142,17 @@ Feature: edit users | another-admin | And user "another-admin" has been added to group "admin" When user "another-admin" changes the quota of user "another-admin" to "12MB" using the provisioning API - And user "another-admin" changes the email of user "another-admin" to "another-admin@example.com" using the provisioning API - And user "another-admin" changes the display of user "another-admin" to "Anne Brown" using the provisioning API - Then the display name of user "another-admin" should be "Anne Brown" - And the email address of user "another-admin" should be "another-admin@example.com" + Then the OCS status code should be "100" + And the HTTP status code should be "200" And the quota definition of user "another-admin" should be "12 MB" + When user "another-admin" changes the email of user "another-admin" to "another-admin@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "another-admin" should be "another-admin@example.com" + When user "another-admin" changes the display of user "another-admin" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "another-admin" should be "Anne Brown" @notToImplementOnOCIS Scenario: a subadmin should be able to edit user information with subadmin permissions in their group @@ -157,11 +165,17 @@ Feature: edit users And user "another-subadmin" has been made a subadmin of group "new-group" And user "subadmin" has been made a subadmin of group "new-group" When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API - And user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API - And user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API - Then the display name of user "another-subadmin" should be "Anne Brown" - And the email address of user "another-subadmin" should be "brand-new-user@example.com" + Then the OCS status code should be "100" + And the HTTP status code should be "200" And the quota definition of user "another-subadmin" should be "12 MB" + When user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "another-subadmin" should be "brand-new-user@example.com" + When user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "another-subadmin" should be "Anne Brown" @notToImplementOnOCIS Scenario: a subadmin should not be able to edit user information of another subadmin of same group @@ -175,15 +189,15 @@ Feature: edit users When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" + And the quota definition of user "another-subadmin" should be "default" When user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" + And the email address of user "another-subadmin" should be "another-subadmin@owncloud.com" When user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" And the display name of user "another-subadmin" should be "Regular User" - And the email address of user "another-subadmin" should be "another-subadmin@owncloud.com" - And the quota definition of user "another-subadmin" should be "default" Scenario: a normal user should not be able to edit another user's information @@ -194,17 +208,32 @@ Feature: edit users When user "Alice" tries to change the display name of user "Brian" to "New Brian" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" + And the display name of user "Brian" should not have changed When user "Alice" tries to change the email of user "Brian" to "brian-new-email@example.com" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" + And the email address of user "Brian" should not have changed + + + Scenario: a normal user should not be able to edit another user's information + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" tries to change the display name of user "Brian" to "New Brian" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" And the display name of user "Brian" should not have changed + When user "Alice" tries to change the email of user "Brian" to "brian-new-email@example.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" And the email address of user "Brian" should not have changed @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario: Admin gives access to users to change their email address Given user "Alice" has been created with default attributes and without skeleton files - When the administrator updates system config key "allow_user_to_change_mail_address" with value "true" and type "boolean" using the occ command - And user "Alice" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "true" and type "boolean" + When user "Alice" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" And the attributes of user "Alice" returned by the API should include @@ -214,8 +243,8 @@ Feature: edit users @notToImplementOnOCIS @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario: Admin does not give access to users to change their email address Given user "Alice" has been created with default attributes and without skeleton files - When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command - And user "Alice" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When user "Alice" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" And the attributes of user "Alice" returned by the API should include @@ -280,8 +309,8 @@ Feature: edit users @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario: Admin gives access to users to change their display name Given user "Alice" has been created with default attributes and without skeleton files - When the administrator updates system config key "allow_user_to_change_display_name" with value "true" and type "boolean" using the occ command - And user "Alice" changes the display of user "Alice" to "Alice Wonderland" using the provisioning API + And the administrator has updated system config key "allow_user_to_change_display_name" with value "true" and type "boolean" + When user "Alice" changes the display of user "Alice" to "Alice Wonderland" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" And the attributes of user "Alice" returned by the API should include @@ -291,8 +320,8 @@ Feature: edit users @notToImplementOnOCIS @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario: Admin does not give access to users to change their display name Given user "Alice" has been created with default attributes and without skeleton files - When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command - And user "Alice" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When user "Alice" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API Then the OCS status code should be "997" And the HTTP status code should be "401" And the attributes of user "Alice" returned by the API should include diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature index 783233b591e7..ecfc4e5026ad 100644 --- a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature @@ -64,7 +64,9 @@ Feature: enable user And user "another-admin" has been added to group "admin" And user "another-admin" has been disabled When user "another-admin" tries to enable user "another-admin" using the provisioning API - Then user "another-admin" should be disabled + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-admin" should be disabled Scenario: normal user tries to enable other user Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature index 59f79f00a345..f3ed2ea5756a 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature @@ -13,10 +13,11 @@ Feature: get subadmins And group "brand-new-group" has been created And user "brand-new-user" has been made a subadmin of group "brand-new-group" When the administrator gets all the subadmins of group "brand-new-group" using the provisioning API - Then the subadmin users returned by the API should be - | brand-new-user | - And the OCS status code should be "100" + Then the OCS status code should be "100" And the HTTP status code should be "200" + And the subadmin users returned by the API should be + | brand-new-user | + Scenario: admin tries to get subadmin users of a group which does not exist Given user "brand-new-user" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature index 972158ec5ef0..1be0473283aa 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getUser.feature @@ -113,56 +113,38 @@ Feature: get user And the last login returned by the API should be a current Unix timestamp @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 - Scenario: a normal user gets their own information, providing uppercase username as authentication + Scenario Outline: a normal user gets their own information, providing uppercase username as authentication and in the URL Given these users have been created with default attributes and without skeleton files: | username | displayname | | brand-new-user | New User | - When user "BRAND-NEW-USER" retrieves the information of user "brand-new-user" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the display name returned by the API should be "New User" - And the quota definition returned by the API should be "default" - And the free, used, total and relative quota returned by the API should exist and be valid numbers - And the last login returned by the API should be a current Unix timestamp - - @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 - Scenario: a normal user gets their own information, providing uppercase username in the URL - Given these users have been created with default attributes and without skeleton files: - | username | displayname | - | brand-new-user | New User | - When user "brand-new-user" retrieves the information of user "BRAND-NEW-USER" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the display name returned by the API should be "New User" - And the quota definition returned by the API should be "default" - And the free, used, total and relative quota returned by the API should exist and be valid numbers - And the last login returned by the API should be a current Unix timestamp - - @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 - Scenario: a mixed-case normal user gets their own information, providing lowercase username in the URL - Given these users have been created with default attributes and without skeleton files: - | username | displayname | - | Brand-New-User | New User | - When user "Brand-New-User" retrieves the information of user "brand-new-user" using the provisioning API + When user "" retrieves the information of user "" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" And the display name returned by the API should be "New User" And the quota definition returned by the API should be "default" And the free, used, total and relative quota returned by the API should exist and be valid numbers And the last login returned by the API should be a current Unix timestamp + Examples: + | username1 | username2 | + | BRAND-NEW-USER | brand-new-user | + | brand-new-user | BRAND-NEW-USER | @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 - Scenario: a mixed-case normal user gets their own information, providing the mixed-case username in the URL + Scenario Outline: a mixed-case normal user gets their own information, providing lowercase and mixed-case username in the URL Given these users have been created with default attributes and without skeleton files: | username | displayname | | Brand-New-User | New User | - When user "brand-new-user" retrieves the information of user "Brand-New-User" using the provisioning API + When user "" retrieves the information of user "" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" And the display name returned by the API should be "New User" And the quota definition returned by the API should be "default" And the free, used, total and relative quota returned by the API should exist and be valid numbers And the last login returned by the API should be a current Unix timestamp + Examples: + | username1 | username2 | + | Brand-New-User | brand-new-user | + | brand-new-user | Brand-New-User | @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Scenario: admin gets information of a user with admin permissions diff --git a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature index 168abac1a68a..c8e354be19f0 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature @@ -35,10 +35,11 @@ Feature: get users And user "brand-new-user" has been added to group "brand-new-group" And user "brand-new-user" has been made a subadmin of group "brand-new-group" When user "brand-new-user" gets the list of all users using the provisioning API - Then the users returned by the API should be - | brand-new-user | - And the OCS status code should be "100" + Then the OCS status code should be "100" And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + Scenario: normal user tries to get other users Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature index 03b5d7f00b63..c3ee0fb25bf2 100644 --- a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature +++ b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature @@ -152,7 +152,9 @@ Feature: reset user password | /remote.php/dav/files/%username%/textfile0.txt | Then the HTTP status code of responses on all endpoints should be "207" When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API - Then the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user" | endpoint | | /remote.php/dav/files/%username%/textfile0.txt |