Merge pull request #33038 from owncloud/editUser-acceptance-test-changes

Refactor edit and get user provisioning API acceptance tests
owncloud · Oct 8, 2018 · eaf2f7e · eaf2f7e
2 parents 7f43ba6 + ba2ee5b
commit eaf2f7e
Show file tree

Hide file tree

Showing 6 changed files with 332 additions and 85 deletions.
diff --git a/tests/TestHelpers/UserHelper.php b/tests/TestHelpers/UserHelper.php
@@ -103,6 +103,30 @@ public static function editUser(
 		);
 	}
 
+	/**
+	 *
+	 * @param string $baseUrl
+	 * @param string $userName
+	 * @param string $adminUser
+	 * @param string $adminPassword
+	 * @param int $ocsApiVersion
+	 *
+	 * @return ResponseInterface
+	 */
+	public static function getUser(
+		$baseUrl, $userName, $adminUser, $adminPassword, $ocsApiVersion = 2
+	) {
+		return OcsApiHelper::sendRequest(
+			$baseUrl,
+			$adminUser,
+			$adminPassword,
+			"GET",
+			"/cloud/users/" . $userName,
+			[],
+			$ocsApiVersion
+		);
+	}
+
 	/**
 	 *
 	 * @param string $baseUrl

diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
@@ -1,24 +1,34 @@
 @api @provisioning_api-app-required
 Feature: edit users
-  As an admin
-  I want to be able to edit a user
-  So that I can change user information
+  As an admin, subadmin or as myself
+  I want to be able to edit user information
+  So that I can keep the user information up-to-date
 
   Background:
     Given using OCS API version "1"
 
   @smokeTest
-  Scenario: Edit a user email
+  Scenario: the administrator can edit a user email
     Given user "brand-new-user" has been created
     When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API
-    And the HTTP status code should be "200"
+    Then the HTTP status code should be "200"
     And the OCS status code should be "100"
     And user "brand-new-user" should exist
     And the user attributes returned by the API should include
       | email | brand-new-user@example.com |
 
   @smokeTest
-  Scenario: Edit a user quota
+  Scenario: the administrator can edit a user display name
+    Given user "brand-new-user" has been created
+    When the administrator changes the display name of user "brand-new-user" to "A New User" using the provisioning API
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "100"
+    And user "brand-new-user" should exist
+    And the user attributes returned by the API should include
+      | displayname | A New User |
+
+  @smokeTest
+  Scenario: the administrator can edit a user quota
     Given user "brand-new-user" has been created
     When the administrator changes the quota of user "brand-new-user" to "12MB" using the provisioning API
     Then the HTTP status code should be "200"
@@ -27,46 +37,73 @@ Feature: edit users
     And the user attributes returned by the API should include
       | quota definition | 12 MB |
 
-  Scenario: Override existing user email
+  Scenario: the administrator can override an existing user email
     Given user "brand-new-user" has been created
     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"
     And the administrator has changed the email of user "brand-new-user" to "brand-new-user@example.com"
     And the OCS status code should be "100"
     And the HTTP status code should be "200"
-    When user "%admin%" sends HTTP method "GET" to OCS API endpoint "/cloud/users/brand-new-user"
+    When the administrator 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 user attributes returned by the API should include
       | email | brand-new-user@example.com |
 
   @smokeTest
-  Scenario: subadmin should be able to edit the user information in his group
+  Scenario: a subadmin should be able to edit the user information in their group
     Given user "subadmin" has been created
     And user "brand-new-user" has been created
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "subadmin" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | quota |
-      | value | 12MB  |
-    And user "subadmin" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | email                      |
-      | value | brand-new-user@example.com |
-    When user "subadmin" sends HTTP method "GET" to OCS API endpoint "/cloud/users/brand-new-user"
+    And user "subadmin" has changed the quota of user "brand-new-user" to "12MB"
+    And user "subadmin" has changed the email of user "brand-new-user" to "brand-new-user@example.com"
+    And user "subadmin" has changed the display name of user "brand-new-user" to "Anne Brown"
+    When user "subadmin" 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 user attributes returned by the API should include
       | quota definition | 12 MB                      |
       | email            | brand-new-user@example.com |
+      | displayname      | Anne Brown                 |
+
+  Scenario: a normal user should be able to change their email address
+    Given user "brand-new-user" has been created
+    When user "brand-new-user" 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 attributes of user "brand-new-user" returned by the API should include
+      | email | brand-new-user@example.com |
+    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 attributes of user "brand-new-user" returned by the API should include
+      | email | brand-new-user@example.com |
 
-  Scenario: normal user should not be able to change their quota
+  Scenario: a normal user should be able to change their display name
     Given user "brand-new-user" has been created
-    When user "brand-new-user" sends HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | quota |
-      | value | 12MB  |
+    When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" 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 "brand-new-user" returned by the API should include
+      | displayname | Alan Border |
+    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 attributes of user "brand-new-user" returned by the API should include
+      | displayname | Alan Border |
+
+  Scenario: a normal user should not be able to change their quota
+    Given user "brand-new-user" has been created
+    When user "brand-new-user" changes the quota of user "brand-new-user" to "12MB" 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 "brand-new-user" returned by the API should include
-      | quota definition | default |
+      | quota definition | default |
+    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 attributes of user "brand-new-user" returned by the API should include
+      | quota definition | default |
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
@@ -1,60 +1,60 @@
 @api @provisioning_api-app-required
 Feature: get user
-  As an admin
-  I want to be able to get user
-  So that I can get information about user
+  As an admin, subadmin or as myself
+  I want to be able to retrieve user information
+  So that I can see the information
 
   Background:
     Given using OCS API version "1"
 
   @smokeTest
   Scenario: admin gets existing user
     Given user "brand-new-user" has been created
-    When user "%admin%" sends HTTP method "GET" to OCS API endpoint "/cloud/users/brand-new-user"
+    When the administrator 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 "brand-new-user"
 
   Scenario: admin tries to get a not existing user
-    When user "%admin%" sends HTTP method "GET" to OCS API endpoint "/cloud/users/test"
+    When the administrator retrieves the information of user "not-a-user" using the provisioning API
     Then the OCS status code should be "998"
     And the HTTP status code should be "200"
     And the API should not return any data
 
   @smokeTest
-  Scenario: subadmin gets information of a user in his group
+  Scenario: a subadmin gets information of a user in their group
     Given user "subadmin" has been created
     And user "newuser" has been created
     And group "newgroup" has been created
     And user "newuser" has been added to group "newgroup"
     And user "subadmin" has been made a subadmin of group "newgroup"
-    When user "subadmin" sends HTTP method "GET" to OCS API endpoint "/cloud/users/newuser"
+    When user "subadmin" retrieves the information of user "newuser" 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 "newuser"
 
-  Scenario: subadmin tries to get information of a user not in his group
+  Scenario: a subadmin tries to get information of a user not in their group
     Given user "subadmin" has been created
     And user "newuser" has been created
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
-    When user "subadmin" sends HTTP method "GET" to OCS API endpoint "/cloud/users/newuser"
+    When user "subadmin" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And the API should not return any data
 
-  Scenario: normal user tries to get information of another user
+  Scenario: a normal user tries to get information of another user
     Given user "newuser" has been created
     And user "anotheruser" has been created
-    When user "anotheruser" sends HTTP method "GET" to OCS API endpoint "/cloud/users/newuser"
+    When user "anotheruser" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And the API should not return any data
 
   @smokeTest
-  Scenario: normal user gets his own information
+  Scenario: a normal user gets their own information
     Given user "newuser" has been created
-    When user "newuser" sends HTTP method "GET" to OCS API endpoint "/cloud/users/newuser"
+    When user "newuser" retrieves the information of user "newuser" 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 "newuser"
+    And the display name returned by the API should be "newuser"
diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
@@ -1,69 +1,109 @@
 @api @provisioning_api-app-required
 Feature: edit users
-  As an admin
-  I want to be able to edit a user
-  So that I can change user information
+  As an admin, subadmin or as myself
+  I want to be able to edit user information
+  So that I can keep the user information up-to-date
 
   Background:
     Given using OCS API version "2"
 
   @smokeTest
-  Scenario: Edit a user
+  Scenario: the administrator can edit a user email
     Given user "brand-new-user" has been created
-    When user "%admin%" sends HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | quota                    |
-      | value | 12MB                     |
-      | key   | email                    |
-      | value | brand-new-user@gmail.com |
-    Then the OCS status code should be "200"
-    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 HTTP status code should be "200"
+    And the OCS status code should be "200"
     And user "brand-new-user" should exist
+    And the user attributes returned by the API should include
+      | email | brand-new-user@example.com |
 
-  Scenario: Override existing user email
+  @smokeTest
+  Scenario: the administrator can edit a user display name
     Given user "brand-new-user" has been created
-    And user "%admin%" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | email                    |
-      | value | brand-new-user@gmail.com |
+    When the administrator changes the display name of user "brand-new-user" to "A New User" using the provisioning API
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "200"
+    And user "brand-new-user" should exist
+    And the user attributes returned by the API should include
+      | displayname | A New User |
+
+  @smokeTest
+  Scenario: the administrator can edit a user quota
+    Given user "brand-new-user" has been created
+    When the administrator changes the quota of user "brand-new-user" to "12MB" using the provisioning API
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "200"
+    And user "brand-new-user" should exist
+    And the user attributes returned by the API should include
+      | quota definition | 12 MB |
+
+  Scenario: the administrator can override existing user email
+    Given user "brand-new-user" has been created
+    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 "200"
     And the HTTP status code should be "200"
-    And user "%admin%" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | email                      |
-      | value | brand-new-user@example.com |
+    And the administrator has changed the email of user "brand-new-user" to "brand-new-user@example.com"
     And the OCS status code should be "200"
     And the HTTP status code should be "200"
-    When user "%admin%" sends HTTP method "GET" to OCS API endpoint "/cloud/users/brand-new-user"
+    When the administrator retrieves the information of user "brand-new-user" using the provisioning API
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
     And the user attributes returned by the API should include
       | email | brand-new-user@example.com |
 
   @smokeTest
-  Scenario: subadmin should be able to edit the user information in his group
+  Scenario: a subadmin should be able to edit the user information in their group
     Given user "subadmin" has been created
     And user "brand-new-user" has been created
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "subadmin" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | quota |
-      | value | 12MB  |
-    And user "subadmin" has sent HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | email                      |
-      | value | brand-new-user@example.com |
-    When user "subadmin" sends HTTP method "GET" to OCS API endpoint "/cloud/users/brand-new-user"
+    And user "subadmin" has changed the quota of user "brand-new-user" to "12MB"
+    And user "subadmin" has changed the email of user "brand-new-user" to "brand-new-user@example.com"
+    And user "subadmin" has changed the display name of user "brand-new-user" to "Anne Brown"
+    When user "subadmin" retrieves the information of user "brand-new-user" using the provisioning API
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
     And the user attributes returned by the API should include
       | quota definition | 12 MB                      |
       | email            | brand-new-user@example.com |
+      | displayname      | Anne Brown                 |
+
+  Scenario: a normal user should be able to change their email address
+    Given user "brand-new-user" has been created
+    When user "brand-new-user" 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 "200"
+    And the HTTP status code should be "200"
+    And the attributes of user "brand-new-user" returned by the API should include
+      | email | brand-new-user@example.com |
+    When user "brand-new-user" retrieves the information of user "brand-new-user" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the attributes of user "brand-new-user" returned by the API should include
+      | email | brand-new-user@example.com |
 
-  @skip @issue-31276
-  Scenario: normal user should not be able to change their quota
+  Scenario: a normal user should be able to change their display name
     Given user "brand-new-user" has been created
-    When user "brand-new-user" sends HTTP method "PUT" to OCS API endpoint "/cloud/users/brand-new-user" with body
-      | key   | quota |
-      | value | 12MB  |
-    Then the OCS status code should be "401"
+    When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the attributes of user "brand-new-user" returned by the API should include
+      | displayname | Alan Border |
+    When user "brand-new-user" retrieves the information of user "brand-new-user" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the attributes of user "brand-new-user" returned by the API should include
+      | displayname | Alan Border |
+
+  Scenario: a normal user should not be able to change their quota
+    Given user "brand-new-user" has been created
+    When user "brand-new-user" changes the quota of user "brand-new-user" to "12MB" 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 "brand-new-user" returned by the API should include
-      | quota definition | default |
+      | quota definition | default |
+    When user "brand-new-user" retrieves the information of user "brand-new-user" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the attributes of user "brand-new-user" returned by the API should include
+      | quota definition | default |