shift existing settings api test scenarios

Signed-off-by: prashant-gurung899 <[email protected]>
owncloud · Jan 15, 2025 · 0c5a30e · 0c5a30e
1 parent 7ba20d5
commit 0c5a30e
Show file tree

Hide file tree

Showing 7 changed files with 62 additions and 47 deletions.
diff --git a/tests/acceptance/bootstrap/GraphContext.php b/tests/acceptance/bootstrap/GraphContext.php
@@ -1864,6 +1864,27 @@ public function userRetrievesAssignedRoleUsingTheGraphApi(string $user): void {
 		);
 	}
 
+	/**
+	 * @When /^user "([^"]*)" tries to get list of assignment using the GRAPH API$/
+	 *
+	 * @param string $user
+	 *
+	 * @return void
+	 *
+	 * @throws GuzzleException
+	 * @throws Exception
+	 */
+	public function getAllExistingRolesUsingTheGraphApi(string $user): void {
+		$response = \TestHelpers\GraphHelper::getAssignedRole(
+			$this->featureContext->getBaseUrl(),
+			'',
+			$user,
+			$this->featureContext->getPasswordForUser($user),
+			$this->featureContext->getUserIdByUserName($user)
+		);
+		$this->featureContext->setResponse($response);
+	}
+
 	/**
 	 * @When /^user "([^"]*)" tries to get the assigned role of user "([^"]*)" using the Graph API$/
 	 *

diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
@@ -361,6 +361,7 @@ default:
         - SettingsContext:
         - SharingNgContext:
         - NotificationContext:
+        - OcisConfigContext:
 
     apiSharingNgShareInvitation:
       paths:

diff --git a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
@@ -21,11 +21,9 @@ The expected failures in this file are from features in the owncloud/ocis repo.
 
 #### [Settings service user can list other peoples assignments](https://github.com/owncloud/ocis/issues/5032)
 
-- [apiAccountsHashDifficulty/assignRole.feature:27](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature#L27)
-- [apiAccountsHashDifficulty/assignRole.feature:28](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature#L28)
-- [apiGraph/getAssignedRole.feature:31](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiGraph/getAssignedRole.feature#L31)
-- [apiGraph/getAssignedRole.feature:32](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiGraph/getAssignedRole.feature#L32)
-- [apiGraph/getAssignedRole.feature:33](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiGraph/getAssignedRole.feature#L33)
+- [apiSettings/settings.feature:116](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSettings/settings.feature#L116)
+- [apiSettings/settings.feature:117](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSettings/settings.feature#L117)
+- [apiSettings/settings.feature:118](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSettings/settings.feature#L118)
 
 #### [A User can get information of another user with Graph API](https://github.com/owncloud/ocis/issues/5125)
 

diff --git a/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature b/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature
@@ -4,35 +4,35 @@ Feature: assign role
   So that I can provide them different authority
 
 
-  Scenario Outline: only admin user can see all existing roles
+  Scenario Outline: user can see all existing roles
     Given user "Alice" has been created with default attributes
     And the administrator has given "Alice" the role "<user-role>" using the settings api
-    When user "Alice" tries to get all existing roles using the settings API
+    When user "Alice" gets all applications using the Graph API
     Then the HTTP status code should be "<http-status-code>"
     Examples:
       | user-role   | http-status-code |
-      | Admin       | 201              |
-      | Space Admin | 201              |
-      | User        | 201              |
+      | Admin       | 200              |
+      | Space Admin | 200              |
+      | User        | 200              |
 
   @issue-5032
   Scenario Outline: only admin user can see assignments list
     Given user "Alice" has been created with default attributes
     And the administrator has given "Alice" the role "<user-role>" using the settings api
-    When user "Alice" tries to get list of assignment using the settings API
+    When user "Alice" tries to get list of assignment using the GRAPH API
     Then the HTTP status code should be "<http-status-code>"
     Examples:
       | user-role   | http-status-code |
-      | Admin       | 201              |
-      | Space Admin | 401              |
-      | User        | 401              |
+      | Admin       | 200              |
+      | Space Admin | 403              |
+      | User        | 403              |
 
 
   Scenario Outline: a user cannot change own role
     Given user "Alice" has been created with default attributes
     And the administrator has given "Alice" the role "<user-role>" using the settings api
-    When user "Alice" changes his own role to "<desired-role>"
-    Then the HTTP status code should be "400"
+    When user "Alice" tries to change the role of user "Alice" to role "<desired-role>" using the Graph API
+    Then the HTTP status code should be "403"
     And user "Alice" should have the role "<user-role>"
     Examples:
       | user-role   | desired-role |
@@ -50,15 +50,15 @@ Feature: assign role
       | Alice    |
       | Brian    |
     And the administrator has given "Alice" the role "<user-role>" using the settings api
-    When user "Alice" changes the role "<desired-role>" for user "Brian"
+    When user "Alice" changes the role of user "Brian" to role "<desired-role>" using the Graph API
     Then the HTTP status code should be "<http-status-code>"
     And user "Brian" should have the role "<expected-role>"
     Examples:
       | user-role   | desired-role | http-status-code | expected-role |
       | Admin       | User         | 201              | User          |
       | Admin       | Space Admin  | 201              | Space Admin   |
       | Admin       | Admin        | 201              | Admin         |
-      | Space Admin | Admin        | 400              | User          |
-      | Space Admin | Space Admin  | 400              | User          |
-      | User        | Admin        | 400              | User          |
-      | User        | Space Admin  | 400              | User          |
+      | Space Admin | Admin        | 403              | User          |
+      | Space Admin | Space Admin  | 403              | User          |
+      | User        | Admin        | 403              | User          |
+      | User        | Space Admin  | 403              | User          |
diff --git a/tests/acceptance/features/apiCors/cors.feature b/tests/acceptance/features/apiCors/cors.feature
@@ -72,16 +72,6 @@ Feature: CORS headers
       | 1               | /apps/files_sharing/api/v1/shares | DELETE         |
       | 2               | /apps/files_sharing/api/v1/shares | POST           |
 
-
-  Scenario: CORS headers should be returned when setting CORS domain sending origin header in the Graph api
-    When user "Alice" lists all available spaces with headers using the Graph API
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the HTTP status code should be "200"
-    And the following headers should be set
-      | header                      | value               |
-      | Access-Control-Allow-Origin | https://aphno.badal |
-
   @issue-8231
   Scenario Outline: CORS headers should be returned when setting CORS domain sending origin header in the Webdav api
     Given using <dav-path-version> DAV path

diff --git a/tests/acceptance/features/apiGraph/getAssignedRole.feature b/tests/acceptance/features/apiGraph/getAssignedRole.feature
@@ -19,19 +19,6 @@ Feature: assign role
       | User        |
       | User Light  |
 
-  @issue-5032
-  Scenario Outline: get assigned role of a user via setting api
-    Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
-    When user "Alice" tries to get list of assignment using the settings API
-    Then the HTTP status code should be "<http-status-code>"
-    And the setting API response should have the role "<user-role>"
-    Examples:
-      | user-role   | http-status-code |
-      | Admin       | 201              |
-      | Space Admin | 401              |
-      | User        | 401              |
-      | User Light  | 401              |
-
 
   Scenario Outline: get role of a user assigned via setting api
     Given the administrator has given "Alice" the role "<user-role>" using the settings api

diff --git a/tests/acceptance/features/apiSettings/settings.feature b/tests/acceptance/features/apiSettings/settings.feature
@@ -81,10 +81,11 @@ Feature: settings api
       """
 
   @issue-5032
-  Scenario: user lists assignments
-    Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
+  Scenario Outline: user lists assignments
+    Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
     When user "Alice" tries to get list of assignment using the settings API
-    Then the HTTP status code should be "201"
+    Then the HTTP status code should be "<http-status-code>"
+    And the setting API response should have the role "<user-role>"
     And the JSON data of the response should match
       """
       {
@@ -109,6 +110,12 @@ Feature: settings api
         }
       }
       """
+    Examples:
+      | user-role   | http-status-code |
+      | Admin       | 201              |
+      | Space Admin | 401              |
+      | User        | 401              |
+      | User Light  | 401              |
 
 
   Scenario: switch language
@@ -275,3 +282,14 @@ Feature: settings api
       | Admin       |
       | Space Admin |
       | User        |
+
+
+  Scenario: CORS headers should be returned when setting CORS domain sending origin header in the Graph api
+    Given the config "OCIS_CORS_ALLOW_ORIGINS" has been set to "https://aphno.badal"
+    When user "Alice" lists all available spaces with headers using the Graph API
+      | header | value               |
+      | Origin | https://aphno.badal |
+    Then the HTTP status code should be "200"
+    And the following headers should be set
+      | header                      | value               |
+      | Access-Control-Allow-Origin | https://aphno.badal |