Improved checks in tests for apiProvisioning-v1 suite

owncloud · Mar 1, 2022 · a3b44b7 · a3b44b7
1 parent 406ecfb
commit a3b44b7
Show file tree

Hide file tree

Showing 9 changed files with 93 additions and 68 deletions.
diff --git 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
@@ -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
@@ -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
@@ -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 "[email protected]"
-    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 "[email protected]" 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 "[email protected]"
-    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
+    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 "[email protected]" 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 "[email protected]"
     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 "[email protected]"
-    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 "[email protected]" 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 "[email protected]" 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 "[email protected]" 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 "[email protected]" 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 "[email protected]" 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 "[email protected]" 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
@@ -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
@@ -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