fix: get test suites for core api tests

remove oc10 specific test suites

provide behat config with make command

fix typo

add missing helpers

.drone.star

@@ -930,10 +930,9 @@ def coreApiTests(ctx, part_number = 1, number_of_parts = 1, storage = "ocis", ac
                              "RUN_PART": part_number,
                              "EXPECTED_FAILURES_FILE": expectedFailuresFile,
                              "UPLOAD_DELETE_WAIT_TIME": "1" if storage == "owncloud" else 0,
-                             "BEHAT_YML": "%s/tests/acceptance/config/behat-core.yml" % (dirs["base"]),
                          },
                          "commands": [
-                             "make -C %s test-acceptance-api" % (dirs["base"]),
+                             "make -C %s test-acceptance-core-api" % (dirs["base"]),
                          ],
                      },
                  ] + failEarly(ctx, early_fail),

Makefile

@@ -69,6 +69,7 @@ help:
 	@echo -e "${GREEN}Testing with test suite natively installed:${RESET}\n"
 	@echo -e "${PURPLE}\tdocs: https://owncloud.dev/ocis/development/testing/#testing-with-test-suite-natively-installed${RESET}\n"
 	@echo -e "\tmake test-acceptance-api\t\t${BLUE}run API acceptance tests${RESET}"
+	@echo -e "\tmake test-acceptance-core-api\t\t${BLUE}run core API acceptance tests${RESET}"
 	@echo -e "\tmake test-paralleldeployment-api\t${BLUE}run API acceptance tests for parallel deployment${RESET}"
 	@echo -e "\tmake clean-tests\t\t\t${BLUE}delete API tests framework dependencies${RESET}"
 	@echo
@@ -103,11 +104,17 @@ clean-tests:
 BEHAT_BIN=vendor-bin/behat/vendor/bin/behat
 # behat config file for parallel deployment tests
 PARALLEL_BEHAT_YML=tests/parallelDeployAcceptance/config/behat.yml
+# behat config file for core api tests
+CORE_BEHAT_YML=tests/acceptance/config/behat-core.yml
 
 .PHONY: test-acceptance-api
 test-acceptance-api: vendor-bin/behat/vendor
 	BEHAT_BIN=$(BEHAT_BIN) $(PWD)/tests/acceptance/run.sh --type api
 
+.PHONY: test-acceptance-core-api
+test-acceptance-core-api: vendor-bin/behat/vendor
+	BEHAT_BIN=$(BEHAT_BIN) BEHAT_YML=$(CORE_BEHAT_YML) $(PWD)/tests/acceptance/run.sh --type core-api
+
 .PHONY: test-paralleldeployment-api
 test-paralleldeployment-api: vendor-bin/behat/vendor
 	BEHAT_BIN=$(BEHAT_BIN) BEHAT_YML=$(PARALLEL_BEHAT_YML) $(PWD)/tests/acceptance/run.sh --type api

tests/TestHelpers/LoggingHelper.php

@@ -0,0 +1,457 @@
+<?php declare(strict_types=1);
+/**
+ * ownCloud
+ *
+ * @author Artur Neumann <artur@jankaritech.com>
+ * @copyright Copyright (c) 2017 Artur Neumann artur@jankaritech.com
+ *
+ * This code is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License,
+ * as published by the Free Software Foundation;
+ * either version 3 of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+namespace TestHelpers;
+
+use Exception;
+use InvalidArgumentException;
+
+/**
+ * Helper to read and analyze the owncloud log file
+ *
+ * @author Artur Neumann <artur@jankaritech.com>
+ *
+ */
+class LoggingHelper {
+	/**
+	 * @var array
+	 */
+	public const LOG_LEVEL_ARRAY = [
+		"debug",
+		"info",
+		"warning",
+		"error",
+		"fatal"
+	];
+
+	/**
+	 * returns the log file path local to the system ownCloud is running on
+	 *
+	 * @param string|null $xRequestId
+	 *
+	 * @return string
+	 * @throws Exception
+	 */
+	public static function getLogFilePath(
+		?string $xRequestId = ''
+	):string {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			return "";
+		}
+		$result = SetupHelper::runOcc(
+			['log:owncloud'],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not get owncloud log file information" .
+				$result ["stdOut"] . " " . $result ["stdErr"]
+			);
+		}
+		\preg_match(
+			"/Log backend ownCloud: (\w+)\sLog file: (.*)/",
+			$result ['stdOut'],
+			$matches
+		);
+		if (!isset($matches[1]) || $matches[1] !== "enabled") {
+			throw new Exception("log backend is not set to 'owncloud'");
+		}
+		if (!isset($matches[2])) {
+			throw new Exception("could not get owncloud log file information");
+		}
+		return $matches[2];
+	}
+
+	/**
+	 *
+	 * @param string|null $baseUrl
+	 * @param string|null $adminUsername
+	 * @param string|null $adminPassword
+	 * @param string|null $xRequestId
+	 * @param int|null $noOfLinesToRead
+	 *
+	 * @return array
+	 * @throws Exception
+	 */
+	public static function getLogFileContent(
+		?string $baseUrl,
+		?string $adminUsername,
+		?string $adminPassword,
+		?string $xRequestId = '',
+		?int $noOfLinesToRead = 0
+	):array {
+		$result = OcsApiHelper::sendRequest(
+			$baseUrl,
+			$adminUsername,
+			$adminPassword,
+			"GET",
+			"/apps/testing/api/v1/logfile/$noOfLinesToRead",
+			$xRequestId
+		);
+		if ($result->getStatusCode() !== 200) {
+			throw new Exception(
+				"could not get logfile content " . $result->getReasonPhrase()
+			);
+		}
+		$response = HttpRequestHelper::getResponseXml($result, __METHOD__);
+
+		$result = [];
+		foreach ($response->data->element as $line) {
+			array_push($result, (string)$line);
+		}
+		return $result;
+	}
+
+	/**
+	 * returns the currently set log level [debug, info, warning, error, fatal]
+	 *
+	 * @param string|null $xRequestId
+	 *
+	 * @return string
+	 * @throws Exception
+	 */
+	public static function getLogLevel(
+		?string $xRequestId = ''
+	):string {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			return "debug";
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not get log level " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+		if (!\preg_match("/Log level:\s(\w+)\s\(/", $result["stdOut"], $matches)) {
+			throw new Exception("could not get log level");
+		}
+		return \strtolower($matches[1]);
+	}
+
+	/**
+	 *
+	 * @param string|null $logLevel (debug|info|warning|error|fatal)
+	 * @param string|null $xRequestId
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public static function setLogLevel(
+		?string $logLevel,
+		?string $xRequestId = ''
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we can't manage log file settings on reva or OCIS
+			return;
+		}
+		if (!\in_array($logLevel, self::LOG_LEVEL_ARRAY)) {
+			throw new InvalidArgumentException("invalid log level");
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage", "--level=$logLevel"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not set log level " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+	}
+
+	/**
+	 * returns the currently set logging backend (owncloud|syslog|errorlog)
+	 *
+	 * @param string|null $xRequestId
+	 *
+	 * @return string
+	 * @throws Exception
+	 */
+	public static function getLogBackend(
+		?string $xRequestId = ''
+	):string {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			return "errorlog";
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not get log backend " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+		$pregResult = \preg_match(
+			"/Enabled logging backend:\s(\w+)\n/",
+			$result ["stdOut"],
+			$matches
+		);
+		if (!$pregResult) {
+			throw new Exception("could not get log backend");
+		}
+		return \strtolower($matches[1]);
+	}
+
+	/**
+	 *
+	 * @param string|null $backend (owncloud|syslog|errorlog)
+	 * @param string|null $xRequestId
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public static function setLogBackend(
+		?string  $backend,
+		?string  $xRequestId = ''
+	):void {
+		if (!\in_array($backend, ["owncloud", "syslog", "errorlog"])) {
+			throw new InvalidArgumentException("invalid log backend");
+		}
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we can't manage log file settings on reva or OCIS
+			return;
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage", "--backend=$backend"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not set log backend " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+	}
+
+	/**
+	 * returns the currently set logging timezone
+	 *
+	 * @param string|null $xRequestId
+	 *
+	 * @return string
+	 * @throws Exception
+	 */
+	public static function getLogTimezone(
+		?string  $xRequestId = ''
+	):string {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			return "UTC";
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not get log timezone " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+		$pregResult = \preg_match(
+			"/Log timezone:\s(\w+)/",
+			$result ["stdOut"],
+			$matches
+		);
+		if (!$pregResult) {
+			throw new Exception("could not get log timezone");
+		}
+		return $matches[1];
+	}
+
+	/**
+	 *
+	 * @param string|null $timezone
+	 * @param string|null $xRequestId
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public static function setLogTimezone(
+		?string $timezone,
+		?string $xRequestId = ''
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we can't manage log file settings on reva or OCIS
+			return;
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage", "--timezone=$timezone"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not set log timezone " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+	}
+
+	/**
+	 *
+	 * @param string|null $baseUrl
+	 * @param string|null $adminUsername
+	 * @param string|null $adminPassword
+	 * @param string|null $xRequestId
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public static function clearLogFile(
+		?string $baseUrl,
+		?string $adminUsername,
+		?string $adminPassword,
+		?string $xRequestId = ''
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			return;
+		}
+		$result = OcsApiHelper::sendRequest(
+			$baseUrl,
+			$adminUsername,
+			$adminPassword,
+			"DELETE",
+			"/apps/testing/api/v1/logfile",
+			$xRequestId
+		);
+		if ($result->getStatusCode() !== 200) {
+			throw new Exception("could not clear logfile");
+		}
+	}
+
+	/**
+	 *
+	 * @param string|null $logLevel
+	 * @param string|null $backend
+	 * @param string|null $timezone
+	 * @param string|null $xRequestId
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public static function restoreLoggingStatus(
+		?string $logLevel,
+		?string $backend,
+		?string $timezone,
+		?string $xRequestId = ''
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			return;
+		}
+		if (!\in_array(\strtolower($logLevel), self::LOG_LEVEL_ARRAY)) {
+			throw new InvalidArgumentException("invalid log level");
+		}
+		if (!\in_array(\strtolower($backend), ["owncloud", "syslog", "errorlog"])) {
+			throw new InvalidArgumentException("invalid log backend");
+		}
+
+		$commands = ["log:manage"];
+
+		if ($timezone) {
+			\array_push($commands, "--timezone=$timezone");
+		}
+		if ($logLevel) {
+			\array_push($commands, "--backend=$backend");
+		}
+		if ($backend) {
+			\array_push($commands, "--level=$logLevel");
+		}
+
+		if (\count($commands) > 1) {
+			$result = SetupHelper::runOcc(
+				$commands,
+				$xRequestId
+			);
+			if ($result["code"] != 0) {
+				throw new Exception(
+					"could not restore log status " . $result ["stdOut"] . " " .
+					$result ["stdErr"]
+				);
+			}
+		}
+	}
+
+	/**
+	 * returns the currently set log level, backend and timezone
+	 *
+	 * @param string|null $xRequestId
+	 *
+	 * @return array|string[]
+	 * @throws Exception
+	 */
+	public static function getLogInfo(
+		?string $xRequestId = ''
+	):array {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			return [
+				"level" => "debug",
+				"backend" => "errorlog",
+				"timezone" => "UTC"
+			];
+		}
+		$result = SetupHelper::runOcc(
+			["log:manage"],
+			$xRequestId
+		);
+		if ($result["code"] != 0) {
+			throw new Exception(
+				"could not get log level " . $result ["stdOut"] . " " .
+				$result ["stdErr"]
+			);
+		}
+
+		$logging = [];
+		if (!\preg_match("/Log level:\s(\w+)\s\(/", $result["stdOut"], $matches)) {
+			throw new Exception("could not get log level");
+		}
+		$logging["level"] = $matches[1];
+
+		$pregResult = \preg_match(
+			"/Log timezone:\s(\w+)/",
+			$result ["stdOut"],
+			$matches
+		);
+		if (!$pregResult) {
+			throw new Exception("could not get log timezone");
+		}
+		$logging["timezone"] = $matches[1];
+
+		$pregResult = \preg_match(
+			"/Enabled logging backend:\s(\w+)\n/",
+			$result ["stdOut"],
+			$matches
+		);
+		if (!$pregResult) {
+			throw new Exception("could not get log backend");
+		}
+		$logging["backend"] = $matches[1];
+
+		return $logging;
+	}
+}

tests/acceptance/config/behat-core.yml

@@ -30,7 +30,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - CorsContext:
         - AuthContext:
 
     coreApiAuthOcs:
@@ -47,7 +46,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - SearchContext:
         - PublicWebDavContext:
@@ -64,15 +62,6 @@ default:
         - OccContext:
         - AppConfigurationContext:
 
-    coreApiComments:
-      paths:
-        - "%paths.base%/../features/coreApiComments"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - CommentsContext:
-        - WebDavPropertiesContext:
-
     coreApiFavorites:
       paths:
         - "%paths.base%/../features/coreApiFavorites"
@@ -84,99 +73,6 @@ default:
         - AppConfigurationContext:
         - OccContext:
 
-    coreApiFederationToRoot1:
-      paths:
-        - "%paths.base%/../features/coreApiFederationToRoot1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - FederationContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
-    coreApiFederationToRoot2:
-      paths:
-        - "%paths.base%/../features/coreApiFederationToRoot2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - FederationContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
-    coreApiFederationToShares1:
-      paths:
-        - "%paths.base%/../features/coreApiFederationToShares1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - FederationContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-        - OccContext:
-
-    coreApiFederationToShares2:
-      paths:
-        - "%paths.base%/../features/coreApiFederationToShares2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - FederationContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-        - OccContext:
-
-    coreApiProvisioning-v1:
-      paths:
-        - "%paths.base%/../features/coreApiProvisioning-v1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - OccUsersGroupsContext:
-        - AuthContext:
-        - PublicWebDavContext:
-
-    coreApiProvisioning-v2:
-      paths:
-        - "%paths.base%/../features/coreApiProvisioning-v2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - OccUsersGroupsContext:
-        - AuthContext:
-        - PublicWebDavContext:
-
-    coreApiProvisioningGroups-v1:
-      paths:
-        - "%paths.base%/../features/coreApiProvisioningGroups-v1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - OccUsersGroupsContext:
-
-    coreApiProvisioningGroups-v2:
-      paths:
-        - "%paths.base%/../features/coreApiProvisioningGroups-v2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - OccUsersGroupsContext:
-
-    coreApiShareCreateSpecialToRoot1:
-      paths:
-        - "%paths.base%/../features/coreApiShareCreateSpecialToRoot1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
     coreApiShareCreateSpecialToShares1:
       paths:
         - "%paths.base%/../features/coreApiShareCreateSpecialToShares1"
@@ -188,17 +84,6 @@ default:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
-    coreApiShareCreateSpecialToRoot2:
-      paths:
-        - "%paths.base%/../features/coreApiShareCreateSpecialToRoot2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
     coreApiShareCreateSpecialToShares2:
       paths:
         - "%paths.base%/../features/coreApiShareCreateSpecialToShares2"
@@ -220,19 +105,6 @@ default:
         - OccContext:
         - AppConfigurationContext:
 
-    coreApiShareManagementToRoot:
-      paths:
-        - "%paths.base%/../features/coreApiShareManagementToRoot"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-        - FilesVersionsContext:
-
     coreApiShareManagementToShares:
       paths:
         - "%paths.base%/../features/coreApiShareManagementToShares"
@@ -246,18 +118,6 @@ default:
         - AppConfigurationContext:
         - FilesVersionsContext:
 
-    coreApiShareManagementBasicToRoot:
-      paths:
-        - "%paths.base%/../features/coreApiShareManagementBasicToRoot"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AuthContext:
-
     coreApiShareManagementBasicToShares:
       paths:
         - "%paths.base%/../features/coreApiShareManagementBasicToShares"
@@ -270,28 +130,6 @@ default:
         - WebDavPropertiesContext:
         - AuthContext:
 
-    coreApiShareOperationsToRoot1:
-      paths:
-        - "%paths.base%/../features/coreApiShareOperationsToRoot1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-
-    coreApiShareOperationsToRoot2:
-      paths:
-        - "%paths.base%/../features/coreApiShareOperationsToRoot2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-
     coreApiShareOperationsToShares1:
       paths:
         - "%paths.base%/../features/coreApiShareOperationsToShares1"
@@ -350,17 +188,6 @@ default:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
-    coreApiShareReshareToRoot1:
-      paths:
-        - "%paths.base%/../features/coreApiShareReshareToRoot1"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-
     coreApiShareReshareToShares1:
       paths:
         - "%paths.base%/../features/coreApiShareReshareToShares1"
@@ -372,18 +199,6 @@ default:
         - TrashbinContext:
         - WebDavPropertiesContext:
 
-    coreApiShareReshareToRoot2:
-      paths:
-        - "%paths.base%/../features/coreApiShareReshareToRoot2"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
     coreApiShareReshareToShares2:
       paths:
         - "%paths.base%/../features/coreApiShareReshareToShares2"
@@ -396,18 +211,6 @@ default:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
-    coreApiShareReshareToRoot3:
-      paths:
-        - "%paths.base%/../features/coreApiShareReshareToRoot3"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
     coreApiShareReshareToShares3:
       paths:
         - "%paths.base%/../features/coreApiShareReshareToShares3"
@@ -420,18 +223,6 @@ default:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
-    coreApiShareUpdateToRoot:
-      paths:
-        - "%paths.base%/../features/coreApiShareUpdateToRoot"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - OccContext:
-        - PublicWebDavContext:
-        - TrashbinContext:
-        - WebDavPropertiesContext:
-        - AppConfigurationContext:
-
     coreApiShareUpdateToShares:
       paths:
         - "%paths.base%/../features/coreApiShareUpdateToShares"
@@ -444,34 +235,6 @@ default:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
-    coreApiSharingNotificationsToRoot:
-      paths:
-        - "%paths.base%/../features/coreApiSharingNotificationsToRoot"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - NotificationsCoreContext:
-        - AppConfigurationContext:
-
-    coreApiSharingNotificationsToShares:
-      paths:
-        - "%paths.base%/../features/coreApiSharingNotificationsToShares"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - NotificationsCoreContext:
-        - AppConfigurationContext:
-        - OccContext:
-
-    coreApiTags:
-      paths:
-        - "%paths.base%/../features/coreApiTags"
-      context: *common_ldap_suite_context
-      contexts:
-        - FeatureContext: *common_feature_context_params
-        - TagsContext:
-        - WebDavPropertiesContext:
-
     coreApiTrashbin:
       paths:
         - "%paths.base%/../features/coreApiTrashbin"
@@ -513,12 +276,10 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - SearchContext:
         - PublicWebDavContext:
         - WebDavPropertiesContext:
-        - TagsContext:
         - TrashbinContext:
 
     coreApiWebdavLocks:
@@ -571,7 +332,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - WebDavPropertiesContext:
 
@@ -581,7 +341,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - WebDavPropertiesContext:
 
@@ -591,12 +350,10 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - SearchContext:
         - PublicWebDavContext:
         - WebDavPropertiesContext:
-        - TagsContext:
         - TrashbinContext:
 
     coreApiWebdavPreviews:
@@ -614,7 +371,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
@@ -625,7 +381,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - WebDavPropertiesContext:
         - AppConfigurationContext:
 
@@ -656,7 +411,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - PublicWebDavContext:
         - TUSContext:
@@ -669,7 +423,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - TrashbinContext:
         - PublicWebDavContext:
@@ -683,7 +436,6 @@ default:
       context: *common_ldap_suite_context
       contexts:
         - FeatureContext: *common_feature_context_params
-        - LoggingContext:
         - OccContext:
         - TrashbinContext:
         - PublicWebDavContext:

tests/acceptance/features/bootstrap/LoggingContext.php

@@ -0,0 +1,617 @@
+<?php declare(strict_types=1);
+/**
+ * ownCloud
+ *
+ * @author Artur Neumann <artur@jankaritech.com>
+ * @copyright Copyright (c) 2018 Artur Neumann artur@jankaritech.com
+ *
+ * This code is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License,
+ * as published by the Free Software Foundation;
+ * either version 3 of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+
+use Behat\Behat\Context\Context;
+use Behat\Behat\Hook\Scope\BeforeScenarioScope;
+use Behat\Gherkin\Node\TableNode;
+use PHPUnit\Framework\Assert;
+use TestHelpers\LoggingHelper;
+use TestHelpers\OcisHelper;
+use TestHelpers\SetupHelper;
+
+require_once 'bootstrap.php';
+
+/**
+ * Context to make the Logging steps available
+ */
+class LoggingContext implements Context {
+	/**
+	 * @var FeatureContext
+	 */
+	private $featureContext;
+
+	private $oldLogLevel = null;
+	private $oldLogBackend = null;
+	private $oldLogTimezone = null;
+
+	/**
+	 * checks for specific rows in the log file.
+	 * order of the table has to be the same as in the log file
+	 * empty cells in the table will not be checked!
+	 *
+	 * @Then /^the last lines of the log file should contain log-entries (with|containing|matching) these attributes:$/
+	 *
+	 * @param string $comparingMode
+	 * @param int $ignoredLines
+	 * @param TableNode|null $expectedLogEntries table with headings that correspond
+	 *                                           to the json keys in the log entry
+	 *                                           e.g.
+	 *                                           |user|app|method|message|
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theLastLinesOfTheLogFileShouldContainEntriesWithTheseAttributes(
+		string    $comparingMode,
+		int       $ignoredLines = 0,
+		?TableNode $expectedLogEntries = null
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			// So skip processing this test step.
+			return;
+		}
+		$ignoredLines = (int) $ignoredLines;
+		//-1 because getRows gives also the header
+		$linesToRead = \count($expectedLogEntries->getRows()) - 1 + $ignoredLines;
+		$logLines = LoggingHelper::getLogFileContent(
+			$this->featureContext->getBaseUrl(),
+			$this->featureContext->getAdminUsername(),
+			$this->featureContext->getAdminPassword(),
+			$this->featureContext->getStepLineRef(),
+			$linesToRead
+		);
+		$lineNo = 0;
+		foreach ($expectedLogEntries as $expectedLogEntry) {
+			$logEntry = \json_decode($logLines[$lineNo], true);
+			if ($logEntry === null) {
+				throw new Exception("the log line :\n{$logLines[$lineNo]} is not valid JSON");
+			}
+
+			foreach (\array_keys($expectedLogEntry) as $attribute) {
+				if ($comparingMode === 'matching') {
+					$expectedLogEntry[$attribute]
+						= $this->featureContext->substituteInLineCodes(
+							$expectedLogEntry[$attribute],
+							null,
+							['preg_quote' => ['/']]
+						);
+				} else {
+					$expectedLogEntry[$attribute]
+						= $this->featureContext->substituteInLineCodes(
+							$expectedLogEntry[$attribute]
+						);
+				}
+
+				if ($expectedLogEntry[$attribute] !== "") {
+					Assert::assertArrayHasKey(
+						$attribute,
+						$logEntry,
+						"could not find attribute: '$attribute' in log entry: '{$logLines[$lineNo]}'"
+					);
+					$message = "log entry:\n{$logLines[$lineNo]}\n";
+					if (!\is_string($logEntry[$attribute])) {
+						$logEntry[$attribute] = \json_encode(
+							$logEntry[$attribute],
+							JSON_UNESCAPED_SLASHES
+						);
+					}
+					if ($comparingMode === 'with') {
+						Assert::assertEquals(
+							$expectedLogEntry[$attribute],
+							$logEntry[$attribute],
+							$message
+						);
+					} elseif ($comparingMode === 'containing') {
+						Assert::assertStringContainsString(
+							$expectedLogEntry[$attribute],
+							$logEntry[$attribute],
+							$message
+						);
+					} elseif ($comparingMode === 'matching') {
+						Assert::assertMatchesRegularExpression(
+							$expectedLogEntry[$attribute],
+							$logEntry[$attribute],
+							$message
+						);
+					} else {
+						throw new \InvalidArgumentException(
+							"$comparingMode is not a valid mode"
+						);
+					}
+				}
+			}
+			$lineNo++;
+			if (($lineNo + $ignoredLines) >= $linesToRead) {
+				break;
+			}
+		}
+	}
+
+	/**
+	 * alternative wording theLastLinesOfTheLogFileShouldContainEntriesWithTheseAttributes()
+	 *
+	 * @Then /^the last lines of the log file, ignoring the last (\d+) lines, should contain log-entries (with|containing|matching) these attributes:$/
+	 *
+	 * @param int $ignoredLines
+	 * @param string $comparingMode
+	 * @param TableNode $expectedLogEntries
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theLastLinesOfTheLogFileIgnoringSomeShouldContainEntries(
+		int       $ignoredLines,
+		string    $comparingMode,
+		TableNode $expectedLogEntries
+	):void {
+		$this->theLastLinesOfTheLogFileShouldContainEntriesWithTheseAttributes(
+			$comparingMode,
+			$ignoredLines,
+			$expectedLogEntries
+		);
+	}
+
+	/**
+	 * alternative wording theLastLinesOfTheLogFileShouldContainEntriesWithTheseAttributes()
+	 *
+	 * @Then /^the last lines of the log file, ignoring the last line, should contain log-entries (with|containing|matching) these attributes:$/
+	 *
+	 * @param string $comparingMode
+	 * @param TableNode $expectedLogEntries
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theLastLinesOfTheLogFileIgnoringLastShouldContainEntries(
+		string    $comparingMode,
+		TableNode $expectedLogEntries
+	):void {
+		$this->theLastLinesOfTheLogFileShouldContainEntriesWithTheseAttributes(
+			$comparingMode,
+			1,
+			$expectedLogEntries
+		);
+	}
+
+	/**
+	 * wrapper around assertLogFileContainsAtLeastOneEntryMatchingTable()
+	 *
+	 * @Then the log file should contain at least one entry matching each of these lines:
+	 *
+	 * @param TableNode $expectedLogEntries table with headings that correspond
+	 *                                      to the json keys in the log entry
+	 *                                      e.g.
+	 *                                      |user|app|method|message|
+	 *
+	 * @return void
+	 * @throws Exception
+	 * @see assertLogFileContainsAtLeastOneEntryMatchingTable()
+	 */
+	public function logFileShouldContainEntriesMatching(
+		TableNode $expectedLogEntries
+	):void {
+		$this->assertLogFileContainsAtLeastOneEntryMatchingTable(
+			true,
+			$expectedLogEntries
+		);
+	}
+
+	/**
+	 * wrapper around assertLogFileContainsAtLeastOneEntryMatchingTable()
+	 *
+	 * @Then the log file should contain at least one entry matching the regular expressions in each of these lines:
+	 *
+	 * @param TableNode $expectedLogEntries
+	 *
+	 * @return void
+	 * @throws Exception
+	 * @see assertLogFileContainsAtLeastOneEntryMatchingTable()
+	 */
+	public function logFileShouldContainEntriesMatchingRegularExpression(
+		TableNode $expectedLogEntries
+	):void {
+		$this->assertLogFileContainsAtLeastOneEntryMatchingTable(
+			true,
+			$expectedLogEntries,
+			true
+		);
+	}
+
+	/**
+	 * @Then the log file should not contain any entry matching the regular expressions in each of these lines:
+	 *
+	 * @param TableNode $expectedLogEntries
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function logFileShouldNotContainAnyTheEntriesMatchingTheRegularExpression(
+		TableNode $expectedLogEntries
+	):void {
+		$this->assertLogFileContainsAtLeastOneEntryMatchingTable(
+			false,
+			$expectedLogEntries,
+			true
+		);
+	}
+
+	/**
+	 * checks that every line in the table has at least one
+	 * corresponding line in the log file
+	 * empty cells in the table will not be checked!
+	 *
+	 * @param boolean $shouldOrNot if true the table entries are expected to match
+	 *                             at least one entry in the log
+	 *                             if false the table entries are expected not
+	 *                             to match any log in the log file
+	 * @param TableNode $expectedLogEntries table with headings that correspond
+	 *                                      to the json keys in the log entry
+	 *                                      e.g.
+	 *                                      |user|app|method|message|
+	 * @param boolean $regexCompare if true the table entries are expected
+	 *                              to be regular expressions
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	private function assertLogFileContainsAtLeastOneEntryMatchingTable(
+		bool      $shouldOrNot,
+		TableNode $expectedLogEntries,
+		bool $regexCompare = false
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			// So skip processing this test step.
+			return;
+		}
+		$logLines = LoggingHelper::getLogFileContent(
+			$this->featureContext->getBaseUrl(),
+			$this->featureContext->getAdminUsername(),
+			$this->featureContext->getAdminPassword(),
+			$this->featureContext->getStepLineRef()
+		);
+		$expectedLogEntries = $expectedLogEntries->getHash();
+		foreach ($logLines as $logLine) {
+			$logEntry = \json_decode($logLine, true);
+			if ($logEntry === null) {
+				throw new Exception("the log line :\n{$logLine} is not valid JSON");
+			}
+			//reindex the array, we might have deleted entries
+			$expectedLogEntries = \array_values($expectedLogEntries);
+			for ($entryNo = 0; $entryNo < \count($expectedLogEntries); $entryNo++) {
+				$count = 0;
+				$expectedLogEntry = $expectedLogEntries[$entryNo];
+				$foundLine = true;
+				foreach (\array_keys($expectedLogEntry) as $attribute) {
+					if ($expectedLogEntry[$attribute] === "") {
+						//don't check empty table entries
+						continue;
+					}
+					if (!\array_key_exists($attribute, $logEntry)) {
+						//this line does not have the attribute we are looking for
+						$foundLine = false;
+						break;
+					}
+					if (!\is_string($logEntry[$attribute])) {
+						$logEntry[$attribute] = \json_encode(
+							$logEntry[$attribute],
+							JSON_UNESCAPED_SLASHES
+						);
+					}
+
+					if ($regexCompare === true) {
+						$expectedLogEntry[$attribute]
+							= $this->featureContext->substituteInLineCodes(
+								$expectedLogEntry[$attribute],
+								null,
+								['preg_quote' => ['/']]
+							);
+						$matchAttribute = \preg_match(
+							$expectedLogEntry[$attribute],
+							$logEntry[$attribute]
+						);
+					} else {
+						$expectedLogEntry[$attribute]
+							= $this->featureContext->substituteInLineCodes(
+								$expectedLogEntry[$attribute]
+							);
+						$matchAttribute
+							= ($expectedLogEntry[$attribute] === $logEntry[$attribute]);
+					}
+					if (!$matchAttribute) {
+						$foundLine = false;
+						break;
+					}
+					if ($matchAttribute and !$shouldOrNot) {
+						$count += 1;
+						Assert::assertNotEquals(
+							$count,
+							\count($expectedLogEntry),
+							"The entry matches"
+						);
+					}
+				}
+				if ($foundLine === true) {
+					unset($expectedLogEntries[$entryNo]);
+				}
+			}
+		}
+		$notFoundLines = \print_r($expectedLogEntries, true);
+		if ($shouldOrNot) {
+			Assert::assertEmpty(
+				$expectedLogEntries,
+				"could not find these expected line(s):\n $notFoundLines"
+			);
+		}
+	}
+
+	/**
+	 * fails if there is at least one line in the log file that matches all
+	 * given attributes
+	 * attributes in the table that are empty will match any value in the
+	 * corresponding attribute in the log file
+	 *
+	 * @Then /^the log file should not contain any log-entries (with|containing) these attributes:$/
+	 *
+	 * @param string $withOrContaining
+	 * @param TableNode $logEntriesExpectedNotToExist table with headings that
+	 *                                                correspond to the json
+	 *                                                keys in the log entry
+	 *                                                e.g.
+	 *                                                |user|app|method|message|
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theLogFileShouldNotContainAnyLogEntriesWithTheseAttributes(
+		$withOrContaining,
+		TableNode $logEntriesExpectedNotToExist
+	):void {
+		if (OcisHelper::isTestingOnOcisOrReva()) {
+			// Currently we don't interact with the log file on reva or OCIS
+			// So skip processing this test step.
+			return;
+		}
+		$logLines = LoggingHelper::getLogFileContent(
+			$this->featureContext->getBaseUrl(),
+			$this->featureContext->getAdminUsername(),
+			$this->featureContext->getAdminPassword(),
+			$this->featureContext->getStepLineRef()
+		);
+		foreach ($logLines as $logLine) {
+			$logEntry = \json_decode($logLine, true);
+			if ($logEntry === null) {
+				throw new Exception("the log line :\n$logLine is not valid JSON");
+			}
+			foreach ($logEntriesExpectedNotToExist as $logEntryExpectedNotToExist) {
+				$match = true; // start by assuming the worst, we match the unwanted log entry
+				foreach (\array_keys($logEntryExpectedNotToExist) as $attribute) {
+					$logEntryExpectedNotToExist[$attribute]
+						= $this->featureContext->substituteInLineCodes(
+							$logEntryExpectedNotToExist[$attribute]
+						);
+
+					if (isset($logEntry[$attribute]) && ($logEntryExpectedNotToExist[$attribute] !== "")) {
+						if ($withOrContaining === 'with') {
+							$match = ($logEntryExpectedNotToExist[$attribute] === $logEntry[$attribute]);
+						} else {
+							$match = (\strpos($logEntry[$attribute], $logEntryExpectedNotToExist[$attribute]) !== false);
+						}
+					}
+					if (!isset($logEntry[$attribute])) {
+						$match = false;
+					}
+					if (!$match) {
+						break;
+					}
+				}
+			}
+			Assert::assertFalse(
+				$match,
+				"found a log entry that should not be there\n$logLine\n"
+			);
+		}
+	}
+
+	/**
+	 * @When the owncloud log level is set to :logLevel
+	 *
+	 * @param string $logLevel (debug|info|warning|error|fatal)
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogLevelIsSetTo(string $logLevel):void {
+		LoggingHelper::setLogLevel(
+			$logLevel,
+			$this->featureContext->getStepLineRef()
+		);
+	}
+
+	/**
+	 * @Given the owncloud log level has been set to :logLevel
+	 *
+	 * @param string $logLevel (debug|info|warning|error|fatal)
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogLevelHasBeenSetTo(string $logLevel):void {
+		$this->owncloudLogLevelIsSetTo($logLevel);
+		$logLevelArray = LoggingHelper::LOG_LEVEL_ARRAY;
+		$logLevelExpected = \array_search($logLevel, $logLevelArray);
+		$logLevelActual = \array_search(
+			LoggingHelper::getLogLevel(
+				$this->featureContext->getStepLineRef()
+			),
+			$logLevelArray
+		);
+		Assert::assertEquals(
+			$logLevelExpected,
+			$logLevelActual,
+			"The expected log level is {$logLevelExpected} but the log level has been set to {$logLevelActual}"
+		);
+	}
+
+	/**
+	 * @When the owncloud log backend is set to :backend
+	 *
+	 * @param string $backend (owncloud|syslog|errorlog)
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogBackendIsSetTo(string $backend):void {
+		LoggingHelper::setLogBackend(
+			$backend,
+			$this->featureContext->getStepLineRef()
+		);
+	}
+
+	/**
+	 * @Given the owncloud log backend has been set to :backend
+	 *
+	 * @param string $expectedBackend (owncloud|syslog|errorlog)
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogBackendHasBeenSetTo(string $expectedBackend):void {
+		$this->owncloudLogBackendIsSetTo($expectedBackend);
+		$currentBackend = LoggingHelper::getLogBackend(
+			$this->featureContext->getStepLineRef()
+		);
+		Assert::assertEquals(
+			$expectedBackend,
+			$currentBackend,
+			"The owncloud log backend was expected to be set to {$expectedBackend} but got {$currentBackend}"
+		);
+	}
+
+	/**
+	 * @When the owncloud log timezone is set to :timezone
+	 *
+	 * @param string $timezone
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogTimezoneIsSetTo(string $timezone):void {
+		LoggingHelper::setLogTimezone(
+			$timezone,
+			$this->featureContext->getStepLineRef()
+		);
+	}
+
+	/**
+	 * @Given the owncloud log timezone has been set to :timezone
+	 *
+	 * @param string $expectedTimezone
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function owncloudLogTimezoneHasBeenSetTo(string $expectedTimezone):void {
+		$this->owncloudLogTimezoneIsSetTo($expectedTimezone);
+		$currentTimezone = LoggingHelper::getLogTimezone(
+			$this->featureContext->getStepLineRef()
+		);
+		Assert::assertEquals(
+			$expectedTimezone,
+			$currentTimezone,
+			"The owncloud log timezone was expected to be set to {$expectedTimezone}, but got {$currentTimezone}"
+		);
+	}
+
+	/**
+	 * @When the owncloud log is cleared
+	 * @Given the owncloud log has been cleared
+	 *
+	 * checks for the httpRequest is done inside clearLogFile function
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theOwncloudLogIsCleared():void {
+		LoggingHelper::clearLogFile(
+			$this->featureContext->getBaseUrl(),
+			$this->featureContext->getAdminUsername(),
+			$this->featureContext->getAdminPassword(),
+			$this->featureContext->getStepLineRef()
+		);
+	}
+
+	/**
+	 * After Scenario for logging. Sets back old log settings
+	 *
+	 * @AfterScenario
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function tearDownScenarioLogging():void {
+		LoggingHelper::restoreLoggingStatus(
+			$this->oldLogLevel,
+			$this->oldLogBackend,
+			$this->oldLogTimezone,
+			$this->featureContext->getStepLineRef()
+		);
+	}
+
+	/**
+	 * @BeforeScenario
+	 *
+	 * @param BeforeScenarioScope $scope
+	 *
+	 * @return void
+	 */
+	public function setUpScenario(BeforeScenarioScope $scope):void {
+		// Get the environment
+		$environment = $scope->getEnvironment();
+		// Get all the contexts you need in this context
+		$this->featureContext = $environment->getContext('FeatureContext');
+		SetupHelper::init(
+			$this->featureContext->getAdminUsername(),
+			$this->featureContext->getAdminPassword(),
+			$this->featureContext->getBaseUrl(),
+			$this->featureContext->getOcPath()
+		);
+	}
+
+	/**
+	 * Before Scenario for logging. Saves current log settings
+	 *
+	 * @BeforeScenario
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function setUpScenarioLogging():void {
+		$logging = LoggingHelper::getLogInfo(
+			$this->featureContext->getStepLineRef()
+		);
+		$this->oldLogLevel = $logging["level"];
+		$this->oldLogBackend = $logging["backend"];
+		$this->oldLogTimezone = $logging["timezone"];
+	}
+}

tests/acceptance/features/bootstrap/ShareesContext.php

@@ -0,0 +1,231 @@
+<?php declare(strict_types=1);
+/**
+ * ownCloud
+ *
+ * @author Joas Schilling <coding@schilljs.com>
+ * @author Sergio Bertolin <sbertolin@owncloud.com>
+ * @author Phillip Davis <phil@jankaritech.com>
+ * @copyright Copyright (c) 2018, ownCloud GmbH
+ *
+ * This code is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License,
+ * as published by the Free Software Foundation;
+ * either version 3 of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+
+use Behat\Behat\Context\Context;
+use Behat\Behat\Hook\Scope\BeforeScenarioScope;
+use Behat\Gherkin\Node\TableNode;
+use Psr\Http\Message\ResponseInterface;
+use PHPUnit\Framework\Assert;
+
+require_once 'bootstrap.php';
+
+/**
+ * Sharees context.
+ */
+class ShareesContext implements Context {
+	/**
+	 *
+	 * @var FeatureContext
+	 */
+	private $featureContext;
+
+	/**
+	 *
+	 * @var OCSContext
+	 */
+	private $ocsContext;
+
+	/**
+	 * @When /^the user gets the sharees using the sharing API with parameters$/
+	 *
+	 * @param TableNode $body
+	 *
+	 * @return void
+	 */
+	public function theUserGetsTheShareesWithParameters(TableNode $body):void {
+		$this->userGetsTheShareesWithParameters(
+			$this->featureContext->getCurrentUser(),
+			$body
+		);
+	}
+
+	/**
+	 * @When /^user "([^"]*)" gets the sharees using the sharing API with parameters$/
+	 *
+	 * @param string $user
+	 * @param TableNode $body
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function userGetsTheShareesWithParameters(string $user, TableNode $body):void {
+		$user = $this->featureContext->getActualUsername($user);
+		$url = '/apps/files_sharing/api/v1/sharees';
+		$this->featureContext->verifyTableNodeColumnsCount($body, 2);
+		if ($body instanceof TableNode) {
+			$parameters = [];
+			foreach ($body->getRowsHash() as $key => $value) {
+				$parameters[] = "$key=$value";
+			}
+			if (!empty($parameters)) {
+				$url .= '?' . \implode('&', $parameters);
+			}
+		}
+
+		$this->ocsContext->userSendsHTTPMethodToOcsApiEndpointWithBody(
+			$user,
+			'GET',
+			$url,
+			null
+		);
+	}
+
+	/**
+	 * @Then /^the "([^"]*)" sharees returned should be$/
+	 *
+	 * @param string $shareeType
+	 * @param TableNode $shareesList
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theShareesReturnedShouldBe(string $shareeType, TableNode $shareesList):void {
+		$this->featureContext->verifyTableNodeColumnsCount($shareesList, 3);
+		$sharees = $shareesList->getRows();
+		$respondedArray = $this->getArrayOfShareesResponded(
+			$this->featureContext->getResponse(),
+			$shareeType
+		);
+		Assert::assertEquals(
+			$sharees,
+			$respondedArray,
+			"Returned sharees do not match the expected ones. See the differences below."
+		);
+	}
+
+	/**
+	 * @Then /^the "([^"]*)" sharees returned should include$/
+	 *
+	 * @param string $shareeType
+	 * @param TableNode $shareesList
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theShareesReturnedShouldInclude(string $shareeType, TableNode $shareesList):void {
+		$this->featureContext->verifyTableNodeColumnsCount($shareesList, 3);
+		$sharees = $shareesList->getRows();
+		$respondedArray = $this->getArrayOfShareesResponded(
+			$this->featureContext->getResponse(),
+			$shareeType
+		);
+		foreach ($sharees as $sharee) {
+			Assert::assertContains(
+				$sharee,
+				$respondedArray,
+				"Returned sharees do not match the expected ones. See the differences below."
+			);
+		}
+	}
+
+	/**
+	 * @Then /^the "([^"]*)" sharees returned should be empty$/
+	 *
+	 * @param string $shareeType
+	 *
+	 * @return void
+	 */
+	public function theShareesReturnedShouldBeEmpty(string $shareeType):void {
+		$respondedArray = $this->getArrayOfShareesResponded(
+			$this->featureContext->getResponse(),
+			$shareeType
+		);
+		if (isset($respondedArray[0])) {
+			// [0] is display name and [2] is user or group id
+			$firstEntry = $respondedArray[0][0] . " (" . $respondedArray[0][2] . ")";
+		} else {
+			$firstEntry = "";
+		}
+
+		Assert::assertEmpty(
+			$respondedArray,
+			"'$shareeType' array should be empty, but it starts with $firstEntry"
+		);
+	}
+
+	/**
+	 * @param ResponseInterface $response
+	 * @param string $shareeType
+	 *
+	 * @return array
+	 * @throws Exception
+	 */
+	public function getArrayOfShareesResponded(
+		ResponseInterface $response,
+		string $shareeType
+	):array {
+		$elements = $this->featureContext->getResponseXml($response, __METHOD__)->data;
+		$elements = \json_decode(\json_encode($elements), true);
+		if (\strpos($shareeType, 'exact ') === 0) {
+			$elements = $elements['exact'];
+			$shareeType = \substr($shareeType, 6);
+		}
+
+		Assert::assertArrayHasKey(
+			$shareeType,
+			$elements,
+			__METHOD__ . " The sharees response does not have key '$shareeType'"
+		);
+
+		$sharees = [];
+		foreach ($elements[$shareeType] as $element) {
+			if (\is_int(\key($element))) {
+				// this is a list of elements instead of just one item,
+				// so return the list
+				foreach ($element as $innerItem) {
+					$sharees[] = [
+						$innerItem['label'],
+						$innerItem['value']['shareType'],
+						$innerItem['value']['shareWith']
+					];
+				}
+			} else {
+				$sharees[] = [
+					$element['label'],
+					$element['value']['shareType'],
+					$element['value']['shareWith']
+				];
+			}
+		}
+		return $sharees;
+	}
+
+	/**
+	 * This will run before EVERY scenario.
+	 * It will set the properties for this object.
+	 *
+	 * @BeforeScenario
+	 *
+	 * @param BeforeScenarioScope $scope
+	 *
+	 * @return void
+	 */
+	public function before(BeforeScenarioScope $scope):void {
+		// Get the environment
+		$environment = $scope->getEnvironment();
+		// Get all the contexts you need in this context
+		$this->featureContext = $environment->getContext('FeatureContext');
+		$this->ocsContext = $environment->getContext('OCSContext');
+	}
+}

tests/acceptance/features/bootstrap/WebDavLockingContext.php

@@ -0,0 +1,700 @@
+<?php declare(strict_types=1);
+/**
+ * ownCloud
+ *
+ * @author Artur Neumann <artur@jankaritech.com>
+ * @copyright Copyright (c) 2018 Artur Neumann artur@jankaritech.com
+ *
+ * This code is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License,
+ * as published by the Free Software Foundation;
+ * either version 3 of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+
+use Behat\Behat\Context\Context;
+use Behat\Behat\Hook\Scope\BeforeScenarioScope;
+use Behat\Gherkin\Node\TableNode;
+use GuzzleHttp\Exception\ConnectException;
+use GuzzleHttp\Exception\GuzzleException;
+use PHPUnit\Framework\Assert;
+use TestHelpers\HttpRequestHelper;
+use TestHelpers\OcsApiHelper;
+use TestHelpers\WebDavHelper;
+
+require_once 'bootstrap.php';
+
+/**
+ * context containing API steps needed for the locking mechanism of webdav
+ */
+class WebDavLockingContext implements Context {
+	/**
+	 *
+	 * @var FeatureContext
+	 */
+	private $featureContext;
+
+	/**
+	 *
+	 * @var PublicWebDavContext
+	 */
+	private $publicWebDavContext;
+
+	/**
+	 *
+	 * @var string[][]
+	 */
+	private $tokenOfLastLock = [];
+
+	/**
+	 *
+	 * @param string $user
+	 * @param string $file
+	 * @param TableNode $properties table with no heading with | property | value |
+	 * @param boolean $public if the file is in a public share or not
+	 * @param boolean $expectToSucceed
+	 *
+	 * @return void
+	 */
+	private function lockFile(
+		$user,
+		$file,
+		TableNode $properties,
+		$public = false,
+		$expectToSucceed = true
+	) {
+		$user = $this->featureContext->getActualUsername($user);
+		$baseUrl = $this->featureContext->getBaseUrl();
+		if ($public === true) {
+			$type = "public-files";
+			$password = null;
+		} else {
+			$type = "files";
+			$password = $this->featureContext->getPasswordForUser($user);
+		}
+		$body
+			= "<?xml version='1.0' encoding='UTF-8'?>" .
+			"<d:lockinfo xmlns:d='DAV:'> ";
+		$headers = [];
+		$this->featureContext->verifyTableNodeRows($properties, [], ['lockscope', 'depth', 'timeout']);
+		$propertiesRows = $properties->getRowsHash();
+		foreach ($propertiesRows as $property => $value) {
+			if ($property === "depth" || $property === "timeout") {
+				//properties that are set in the header not in the xml
+				$headers[$property] = $value;
+			} else {
+				$body .= "<d:$property><d:$value/></d:$property>";
+			}
+		}
+
+		$body .= "</d:lockinfo>";
+		$response = WebDavHelper::makeDavRequest(
+			$baseUrl,
+			$user,
+			$password,
+			"LOCK",
+			$file,
+			$headers,
+			$this->featureContext->getStepLineRef(),
+			$body,
+			$this->featureContext->getDavPathVersion(),
+			$type
+		);
+
+		$this->featureContext->setResponse($response);
+		$responseXml = $this->featureContext->getResponseXml(null, __METHOD__);
+		$this->featureContext->setResponseXmlObject($responseXml);
+		$xmlPart = $responseXml->xpath("//d:locktoken/d:href");
+		if (isset($xmlPart[0])) {
+			$this->tokenOfLastLock[$user][$file] = (string) $xmlPart[0];
+		} else {
+			if ($expectToSucceed === true) {
+				Assert::fail("could not find lock token after trying to lock '$file'");
+			}
+		}
+	}
+
+	/**
+	 * @When user :user locks file/folder :file using the WebDAV API setting the following properties
+	 *
+	 * @param string $user
+	 * @param string $file
+	 * @param TableNode $properties table with no heading with | property | value |
+	 *
+	 * @return void
+	 */
+	public function lockFileUsingWebDavAPI($user, $file, TableNode $properties) {
+		$this->lockFile($user, $file, $properties, false, false);
+	}
+
+	/**
+	 * @Given user :user has locked file/folder :file setting the following properties
+	 *
+	 * @param string $user
+	 * @param string $file
+	 * @param TableNode $properties table with no heading with | property | value |
+	 *
+	 * @return void
+	 */
+	public function userHasLockedFile($user, $file, TableNode $properties) {
+		$this->lockFile($user, $file, $properties, false, true);
+	}
+
+	/**
+	 * @Given the public has locked the last public link shared file/folder setting the following properties
+	 *
+	 * @param TableNode $properties
+	 *
+	 * @return void
+	 */
+	public function publicHasLockedLastSharedFile(TableNode $properties) {
+		$this->lockFile(
+			$this->featureContext->getLastPublicShareToken(),
+			"/",
+			$properties,
+			true
+		);
+	}
+
+	/**
+	 * @When the public locks the last public link shared file/folder using the WebDAV API setting the following properties
+	 *
+	 * @param TableNode $properties
+	 *
+	 * @return void
+	 */
+	public function publicLocksLastSharedFile(TableNode $properties) {
+		$this->lockFile(
+			$this->featureContext->getLastPublicShareToken(),
+			"/",
+			$properties,
+			true,
+			false
+		);
+	}
+
+	/**
+	 * @Given the public has locked :file in the last public link shared folder setting the following properties
+	 *
+	 * @param string $file
+	 * @param TableNode $properties
+	 *
+	 * @return void
+	 */
+	public function publicHasLockedFileLastSharedFolder(
+		$file,
+		TableNode $properties
+	) {
+		$this->lockFile(
+			$this->featureContext->getLastPublicShareToken(),
+			$file,
+			$properties,
+			true
+		);
+	}
+
+	/**
+	 * @When /^the public locks "([^"]*)" in the last public link shared folder using the (old|new) public WebDAV API setting the following properties$/
+	 *
+	 * @param string $file
+	 * @param string $publicWebDAVAPIVersion
+	 * @param TableNode $properties
+	 *
+	 * @return void
+	 */
+	public function publicLocksFileLastSharedFolder(
+		$file,
+		$publicWebDAVAPIVersion,
+		TableNode $properties
+	) {
+		$this->lockFile(
+			$this->featureContext->getLastPublicShareToken(),
+			$file,
+			$properties,
+			true,
+			false
+		);
+	}
+
+	/**
+	 * @When user :user unlocks the last created lock of file/folder :file using the WebDAV API
+	 *
+	 * @param string $user
+	 * @param string $file
+	 *
+	 * @return void
+	 */
+	public function unlockLastLockUsingWebDavAPI($user, $file) {
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$file,
+			$user,
+			$file
+		);
+	}
+
+	/**
+	 * @When user :user unlocks file/folder :itemToUnlock with the last created lock of file/folder :itemToUseLockOf using the WebDAV API
+	 *
+	 * @param string $user
+	 * @param string $itemToUnlock
+	 * @param string $itemToUseLockOf
+	 *
+	 * @return void
+	 */
+	public function unlockItemWithLastLockOfOtherItemUsingWebDavAPI(
+		$user,
+		$itemToUnlock,
+		$itemToUseLockOf
+	) {
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$itemToUnlock,
+			$user,
+			$itemToUseLockOf
+		);
+	}
+
+	/**
+	 * @When user :user unlocks file/folder :itemToUnlock with the last created public lock of file/folder :itemToUseLockOf using the WebDAV API
+	 *
+	 * @param string $user
+	 * @param string $itemToUnlock
+	 * @param string $itemToUseLockOf
+	 *
+	 * @return void
+	 */
+	public function unlockItemWithLastPublicLockOfOtherItemUsingWebDavAPI(
+		$user,
+		$itemToUnlock,
+		$itemToUseLockOf
+	) {
+		$lockOwner = $this->featureContext->getLastPublicShareToken();
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$itemToUnlock,
+			$lockOwner,
+			$itemToUseLockOf
+		);
+	}
+
+	/**
+	 *
+	 * @param string $user
+	 * @param string $itemToUnlock
+	 *
+	 * @return int|void
+	 *
+	 * @throws Exception|GuzzleException
+	 */
+	private function countLockOfResources(
+		string $user,
+		string $itemToUnlock
+	) {
+		$user = $this->featureContext->getActualUsername($user);
+		$baseUrl = $this->featureContext->getBaseUrl();
+		$password = $this->featureContext->getPasswordForUser($user);
+		$body
+			= "<?xml version='1.0' encoding='UTF-8'?>" .
+			"<d:propfind xmlns:d='DAV:'> " .
+			"<d:prop><d:lockdiscovery/></d:prop>" .
+			"</d:propfind>";
+		$response = WebDavHelper::makeDavRequest(
+			$baseUrl,
+			$user,
+			$password,
+			"PROPFIND",
+			$itemToUnlock,
+			null,
+			$this->featureContext->getStepLineRef(),
+			$body,
+			$this->featureContext->getDavPathVersion()
+		);
+		$responseXml = $this->featureContext->getResponseXml($response, __METHOD__);
+		$xmlPart = $responseXml->xpath("//d:response//d:lockdiscovery/d:activelock");
+		if (\is_array($xmlPart)) {
+			return \count($xmlPart);
+		} else {
+			throw new Exception("xmlPart for 'd:activelock' was expected to be array but found: $xmlPart");
+		}
+	}
+
+	/**
+	 * @Given user :user has unlocked file/folder :itemToUnlock with the last created lock of file/folder :itemToUseLockOf of user :lockOwner using the WebDAV API
+	 *
+	 * @param string $user
+	 * @param string $itemToUnlock
+	 * @param string $lockOwner
+	 * @param string $itemToUseLockOf
+	 * @param boolean $public
+	 *
+	 * @return void
+	 * @throws Exception|GuzzleException
+	 */
+	public function hasUnlockItemWithTheLastCreatedLock(
+		$user,
+		$itemToUnlock,
+		$lockOwner,
+		$itemToUseLockOf,
+		$public = false
+	) {
+		$lockCount = $this->countLockOfResources($user, $itemToUnlock);
+
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$itemToUnlock,
+			$lockOwner,
+			$itemToUseLockOf,
+			$public
+		);
+		$this->featureContext->theHTTPStatusCodeShouldBe(204);
+
+		$this->numberOfLockShouldBeReported($lockCount - 1, $itemToUnlock, $user);
+	}
+
+	/**
+	 * @When user :user unlocks file/folder :itemToUnlock with the last created lock of file/folder :itemToUseLockOf of user :lockOwner using the WebDAV API
+	 *
+	 * @param string $user
+	 * @param string $itemToUnlock
+	 * @param string $lockOwner
+	 * @param string $itemToUseLockOf
+	 * @param boolean $public
+	 *
+	 * @return void
+	 */
+	public function unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+		string $user,
+		string $itemToUnlock,
+		string $lockOwner,
+		string $itemToUseLockOf,
+		bool $public = false
+	) {
+		$user = $this->featureContext->getActualUsername($user);
+		$lockOwner = $this->featureContext->getActualUsername($lockOwner);
+		if ($public === true) {
+			$type = "public-files";
+			$password = null;
+		} else {
+			$type = "files";
+			$password = $this->featureContext->getPasswordForUser($user);
+		}
+		$baseUrl = $this->featureContext->getBaseUrl();
+		if (!isset($this->tokenOfLastLock[$lockOwner][$itemToUseLockOf])) {
+			Assert::fail(
+				"could not find saved token of '$itemToUseLockOf' " .
+				"owned by user '$lockOwner'"
+			);
+		}
+		$headers = [
+			"Lock-Token" => $this->tokenOfLastLock[$lockOwner][$itemToUseLockOf]
+		];
+		$this->featureContext->setResponse(
+			WebDavHelper::makeDavRequest(
+				$baseUrl,
+				$user,
+				$password,
+				"UNLOCK",
+				$itemToUnlock,
+				$headers,
+				$this->featureContext->getStepLineRef(),
+				null,
+				$this->featureContext->getDavPathVersion(),
+				$type
+			)
+		);
+		$this->featureContext->pushToLastStatusCodesArrays();
+	}
+
+	/**
+	 * @When the public unlocks file/folder :itemToUnlock with the last created lock of file/folder :itemToUseLockOf of user :lockOwner using the WebDAV API
+	 *
+	 * @param string $itemToUnlock
+	 * @param string $lockOwner
+	 * @param string $itemToUseLockOf
+	 *
+	 * @return void
+	 */
+	public function unlockItemAsPublicWithLastLockOfUserAndItemUsingWebDavAPI(
+		$itemToUnlock,
+		$lockOwner,
+		$itemToUseLockOf
+	) {
+		$user = $this->featureContext->getLastPublicShareToken();
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$itemToUnlock,
+			$lockOwner,
+			$itemToUseLockOf,
+			true
+		);
+	}
+
+	/**
+	 * @When the public unlocks file/folder :itemToUnlock using the WebDAV API
+	 *
+	 * @param string $itemToUnlock
+	 *
+	 * @return void
+	 */
+	public function unlockItemAsPublicUsingWebDavAPI($itemToUnlock) {
+		$user = $this->featureContext->getLastPublicShareToken();
+		$this->unlockItemWithLastLockOfUserAndItemUsingWebDavAPI(
+			$user,
+			$itemToUnlock,
+			$user,
+			$itemToUnlock,
+			true
+		);
+	}
+
+	/**
+	 * @When /^user "([^"]*)" moves (?:file|folder|entry) "([^"]*)" to "([^"]*)" sending the locktoken of (?:file|folder|entry) "([^"]*)" using the WebDAV API$/
+	 *
+	 * @param string $user
+	 * @param string $fileSource
+	 * @param string $fileDestination
+	 * @param string $itemToUseLockOf
+	 *
+	 * @return void
+	 */
+	public function moveItemSendingLockToken(
+		$user,
+		$fileSource,
+		$fileDestination,
+		$itemToUseLockOf
+	) {
+		$this->moveItemSendingLockTokenOfUser(
+			$user,
+			$fileSource,
+			$fileDestination,
+			$itemToUseLockOf,
+			$user
+		);
+	}
+
+	/**
+	 * @When /^user "([^"]*)" moves (?:file|folder|entry) "([^"]*)" to "([^"]*)" sending the locktoken of (?:file|folder|entry) "([^"]*)" of user "([^"]*)" using the WebDAV API$/
+	 *
+	 * @param string $user
+	 * @param string $fileSource
+	 * @param string $fileDestination
+	 * @param string $itemToUseLockOf
+	 * @param string $lockOwner
+	 *
+	 * @return void
+	 */
+	public function moveItemSendingLockTokenOfUser(
+		$user,
+		$fileSource,
+		$fileDestination,
+		$itemToUseLockOf,
+		$lockOwner
+	) {
+		$user = $this->featureContext->getActualUsername($user);
+		$lockOwner = $this->featureContext->getActualUsername($lockOwner);
+		$destination = $this->featureContext->destinationHeaderValue(
+			$user,
+			$fileDestination
+		);
+		$token = $this->tokenOfLastLock[$lockOwner][$itemToUseLockOf];
+		$headers = [
+			"Destination" => $destination,
+			"If" => "(<$token>)"
+		];
+		try {
+			$response = $this->featureContext->makeDavRequest(
+				$user,
+				"MOVE",
+				$fileSource,
+				$headers
+			);
+			$this->featureContext->setResponse($response);
+		} catch (ConnectException $e) {
+		}
+	}
+
+	/**
+	 * @When /^user "([^"]*)" uploads file with content "([^"]*)" to "([^"]*)" sending the locktoken of (?:file|folder|entry) "([^"]*)" using the WebDAV API$/
+	 *
+	 * @param string $user
+	 * @param string $content
+	 * @param string $destination
+	 * @param string $itemToUseLockOf
+	 *
+	 * @return void
+	 */
+	public function userUploadsAFileWithContentTo(
+		$user,
+		$content,
+		$destination,
+		$itemToUseLockOf
+	) {
+		$user = $this->featureContext->getActualUsername($user);
+		$token = $this->tokenOfLastLock[$user][$itemToUseLockOf];
+		$this->featureContext->pauseUploadDelete();
+		$response = $this->featureContext->makeDavRequest(
+			$user,
+			"PUT",
+			$destination,
+			["If" => "(<$token>)"],
+			$content
+		);
+		$this->featureContext->setResponse($response);
+		$this->featureContext->setLastUploadDeleteTime(\time());
+	}
+
+	/**
+	 * @When /^the public uploads file "([^"]*)" with content "([^"]*)" sending the locktoken of file "([^"]*)" of user "([^"]*)" using the (old|new) public WebDAV API$/
+	 *
+	 * @param string $filename
+	 * @param string $content
+	 * @param string $itemToUseLockOf
+	 * @param string $lockOwner
+	 * @param string $publicWebDAVAPIVersion
+	 *
+	 * @return void
+	 *
+	 */
+	public function publicUploadFileSendingLockTokenOfUser(
+		$filename,
+		$content,
+		$itemToUseLockOf,
+		$lockOwner,
+		$publicWebDAVAPIVersion
+	) {
+		$lockOwner = $this->featureContext->getActualUsername($lockOwner);
+		$headers = [
+			"If" => "(<" . $this->tokenOfLastLock[$lockOwner][$itemToUseLockOf] . ">)"
+		];
+		$this->publicWebDavContext->publicUploadContent(
+			$filename,
+			'',
+			$content,
+			false,
+			$headers,
+			$publicWebDAVAPIVersion
+		);
+	}
+
+	/**
+	 * @When /^the public uploads file "([^"]*)" with content "([^"]*)" sending the locktoken of "([^"]*)" of the public using the (old|new) public WebDAV API$/
+	 *
+	 * @param string $filename
+	 * @param string $content
+	 * @param string $itemToUseLockOf
+	 * @param string $publicWebDAVAPIVersion
+	 *
+	 * @return void
+	 */
+	public function publicUploadFileSendingLockTokenOfPublic(
+		$filename,
+		$content,
+		$itemToUseLockOf,
+		$publicWebDAVAPIVersion
+	) {
+		$lockOwner = $this->featureContext->getLastPublicShareToken();
+		$this->publicUploadFileSendingLockTokenOfUser(
+			$filename,
+			$content,
+			$itemToUseLockOf,
+			$lockOwner,
+			$publicWebDAVAPIVersion
+		);
+	}
+
+	/**
+	 * @Then :count locks should be reported for file/folder :file of user :user by the WebDAV API
+	 *
+	 * @param int $count
+	 * @param string $file
+	 * @param string $user
+	 *
+	 * @return void
+	 * @throws GuzzleException
+	 */
+	public function numberOfLockShouldBeReported($count, $file, $user) {
+		$lockCount = $this->countLockOfResources($user, $file);
+		Assert::assertEquals(
+			$count,
+			$lockCount,
+			"Expected $count lock(s) for '$file' but found '$lockCount'"
+		);
+	}
+
+	/**
+	 * @Then group :expectedGroup should exist as a lock breaker group
+	 *
+	 * @param string $expectedGroup
+	 *
+	 * @return void
+	 *
+	 * @throws Exception
+	 */
+	public function groupShouldExistAsLockBreakerGroups($expectedGroup) {
+		$baseUrl = $this->featureContext->getBaseUrl();
+		$admin = $this->featureContext->getAdminUsername();
+		$password = $this->featureContext->getAdminPassword();
+		$ocsApiVersion = $this->featureContext->getOcsApiVersion();
+
+		$response = OcsApiHelper::sendRequest(
+			$baseUrl,
+			$admin,
+			$password,
+			'GET',
+			"/apps/testing/api/v1/app/core/lock-breaker-groups",
+			(string) $ocsApiVersion
+		);
+
+		$responseXml = HttpRequestHelper::getResponseXml($response, __METHOD__)->data->element;
+		$lockbreakergroup = trim(\json_decode(\json_encode($responseXml), true)['value'], '\'[]"');
+		$actualgroup = explode("\",\"", $lockbreakergroup);
+		if (!\in_array($expectedGroup, $actualgroup)) {
+			Assert::fail("could not find group '$expectedGroup' in lock breakers group");
+		}
+	}
+
+	/**
+	 * @Then following groups should exist as lock breaker groups
+	 *
+	 * @param TableNode $table
+	 *
+	 * @return void
+	 *
+	 * @throws Exception
+	 */
+	public function followingGroupShouldExistAsLockBreakerGroups(TableNode $table) {
+		$this->featureContext->verifyTableNodeColumns($table, ["groups"]);
+		$paths = $table->getHash();
+
+		foreach ($paths as $group) {
+			$this->groupShouldExistAsLockBreakerGroups($group["groups"]);
+		}
+	}
+
+	/**
+	 * This will run before EVERY scenario.
+	 * It will set the properties for this object.
+	 *
+	 * @BeforeScenario
+	 *
+	 * @param BeforeScenarioScope $scope
+	 *
+	 * @return void
+	 */
+	public function before(BeforeScenarioScope $scope) {
+		// Get the environment
+		$environment = $scope->getEnvironment();
+		// Get all the contexts you need in this context
+		$this->featureContext = $environment->getContext('FeatureContext');
+		$this->publicWebDavContext = $environment->getContext('PublicWebDavContext');
+	}
+}

tests/acceptance/features/coreApiAuth/cors.feature

@@ -1,209 +0,0 @@
-@api @issue-ocis-reva-26 @issue-ocis-reva-27 @skipOnOcis
-Feature: CORS headers
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-
-  Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header
-    Given using OCS API version "<ocs_api_version>"
-    And user "Alice" has added "https://aphno.badal" to the list of personal CORS domains
-    When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should be set
-      | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-      | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,Cache-Control,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-      | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,OC-RequestAppPassword,Vary,Webdav-Location,X-Sabre-Status                                                                                                                                                                                                                                                                                                                                                                                                                     |
-      | Access-Control-Allow-Origin   | https://aphno.badal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-      | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /privatedata/getattribute                        | 100      | 200       |
-      | 2               | /privatedata/getattribute                        | 200      | 200       |
-      | 1               | /cloud/apps                                      | 997      | 401       |
-      | 2               | /cloud/apps                                      | 997      | 401       |
-      | 1               | /cloud/groups                                    | 997      | 401       |
-      | 2               | /cloud/groups                                    | 997      | 401       |
-      | 1               | /cloud/users                                     | 997      | 401       |
-      | 2               | /cloud/users                                     | 997      | 401       |
-      | 1               | /config                                          | 100      | 200       |
-      | 2               | /config                                          | 200      | 200       |
-
-    @files_external-app-required @notToImplementOnOCIS
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_external/api/v1/mounts               | 100      | 200       |
-      | 2               | /apps/files_external/api/v1/mounts               | 200      | 200       |
-
-    @files_sharing-app-required
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_sharing/api/v1/remote_shares         | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares         | 200      | 200       |
-      | 1               | /apps/files_sharing/api/v1/remote_shares/pending | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares/pending | 200      | 200       |
-      | 1               | /apps/files_sharing/api/v1/shares                | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/shares                | 200      | 200       |
-
-
-  Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header (admin only endpoints)
-    Given using OCS API version "<ocs_api_version>"
-    And the administrator has added "https://aphno.badal" to the list of personal CORS domains
-    When the administrator sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should be set
-      | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-      | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,Cache-Control,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-      | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,OC-RequestAppPassword,Vary,Webdav-Location,X-Sabre-Status                                                                                                                                                                                                                                                                                                                                                                                                                     |
-      | Access-Control-Allow-Origin   | https://aphno.badal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-      | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-    Examples:
-      | ocs_api_version | endpoint      | ocs-code | http-code |
-      | 1               | /cloud/apps   | 100      | 200       |
-      | 2               | /cloud/apps   | 200      | 200       |
-      | 1               | /cloud/groups | 100      | 200       |
-      | 2               | /cloud/groups | 200      | 200       |
-      | 1               | /cloud/users  | 100      | 200       |
-      | 2               | /cloud/users  | 200      | 200       |
-
-
-  Scenario Outline: no CORS headers should be returned when CORS domain does not match Origin header
-    Given using OCS API version "<ocs_api_version>"
-    And user "Alice" has added "https://mero.badal" to the list of personal CORS domains
-    When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should not be set
-      | header                        |
-      | Access-Control-Allow-Headers  |
-      | Access-Control-Expose-Headers |
-      | Access-Control-Allow-Origin   |
-      | Access-Control-Allow-Methods  |
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /config                                          | 100      | 200       |
-      | 2               | /config                                          | 200      | 200       |
-      | 1               | /privatedata/getattribute                        | 100      | 200       |
-      | 2               | /privatedata/getattribute                        | 200      | 200       |
-      | 1               | /cloud/apps                                      | 997      | 401       |
-      | 2               | /cloud/apps                                      | 997      | 401       |
-      | 1               | /cloud/groups                                    | 997      | 401       |
-      | 2               | /cloud/groups                                    | 997      | 401       |
-      | 1               | /cloud/users                                     | 997      | 401       |
-      | 2               | /cloud/users                                     | 997      | 401       |
-
-    @files_external-app-required @notToImplementOnOCIS
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_external/api/v1/mounts               | 100      | 200       |
-      | 2               | /apps/files_external/api/v1/mounts               | 200      | 200       |
-
-    @files_sharing-app-required
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_sharing/api/v1/remote_shares         | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares         | 200      | 200       |
-      | 1               | /apps/files_sharing/api/v1/remote_shares/pending | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares/pending | 200      | 200       |
-      | 1               | /apps/files_sharing/api/v1/shares                | 100      | 200       |
-      | 2               | /apps/files_sharing/api/v1/shares                | 200      | 200       |
-
-
-  Scenario Outline: no CORS headers should be returned when CORS domain does not match Origin header (admin only endpoints)
-    Given using OCS API version "<ocs_api_version>"
-    And the administrator has added "https://mero.badal" to the list of personal CORS domains
-    When the administrator sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should not be set
-      | header                        |
-      | Access-Control-Allow-Headers  |
-      | Access-Control-Expose-Headers |
-      | Access-Control-Allow-Origin   |
-      | Access-Control-Allow-Methods  |
-    Examples:
-      | ocs_api_version | endpoint      | ocs-code | http-code |
-      | 1               | /cloud/apps   | 100      | 200       |
-      | 2               | /cloud/apps   | 200      | 200       |
-      | 1               | /cloud/groups | 100      | 200       |
-      | 2               | /cloud/groups | 200      | 200       |
-      | 1               | /cloud/users  | 100      | 200       |
-      | 2               | /cloud/users  | 200      | 200       |
-
-  @issue-34679 @skipOnOcV10
-  Scenario Outline: CORS headers should be returned when invalid password is used
-    Given using OCS API version "<ocs_api_version>"
-    And user "Alice" has added "https://aphno.badal" to the list of personal CORS domains
-    When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers using password "invalid"
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should be set
-      | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-      | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,Cache-Control,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-      | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,OC-RequestAppPassword,Vary,Webdav-Location,X-Sabre-Status                                                                                                                                                                                                                                                                                                                                                                                                                     |
-      | Access-Control-Allow-Origin   | https://aphno.badal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-      | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /privatedata/getattribute                        | 997      | 401       |
-      | 2               | /privatedata/getattribute                        | 997      | 401       |
-      | 1               | /cloud/apps                                      | 997      | 401       |
-      | 2               | /cloud/apps                                      | 997      | 401       |
-      | 1               | /cloud/groups                                    | 997      | 401       |
-      | 2               | /cloud/groups                                    | 997      | 401       |
-      | 1               | /cloud/users                                     | 997      | 401       |
-      | 2               | /cloud/users                                     | 997      | 401       |
-
-    @files_external-app-required @notToImplementOnOCIS
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_external/api/v1/mounts               | 997      | 401       |
-      | 2               | /apps/files_external/api/v1/mounts               | 997      | 401       |
-
-    @files_sharing-app-required
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_sharing/api/v1/remote_shares         | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares         | 997      | 401       |
-      | 1               | /apps/files_sharing/api/v1/remote_shares/pending | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares/pending | 997      | 401       |
-      | 1               | /apps/files_sharing/api/v1/shares                | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/shares                | 997      | 401       |
-
-  @issue-34679 @skipOnOcV10
-  Scenario Outline: CORS headers should be returned when invalid password is used (admin only endpoints)
-    Given using OCS API version "<ocs_api_version>"
-    And the administrator has added "https://aphno.badal" to the list of personal CORS domains
-    And user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers using password "invalid"
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should be set
-      | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-      | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,Cache-Control,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-      | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,OC-RequestAppPassword,Vary,Webdav-Location,X-Sabre-Status                                                                                                                                                                                                                                                                                                                                                                                                                     |
-      | Access-Control-Allow-Origin   | https://aphno.badal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-      | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-    Examples:
-      | ocs_api_version | endpoint      | ocs-code | http-code |
-      | 1               | /cloud/apps   | 997      | 401       |
-      | 2               | /cloud/apps   | 997      | 401       |
-      | 1               | /cloud/groups | 997      | 401       |
-      | 2               | /cloud/groups | 997      | 401       |
-      | 1               | /cloud/users  | 997      | 401       |
-      | 2               | /cloud/users  | 997      | 401       |

tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature

@@ -1,85 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: CORS headers current oC10 behavior for issue-34679
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @issue-34679
-  Scenario Outline: CORS headers should be returned when invalid password is used
-    Given using OCS API version "<ocs_api_version>"
-    And user "Alice" has added "https://aphno.badal" to the list of personal CORS domains
-    When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers using password "invalid"
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should not be set
-      | header                        |
-      | Access-Control-Allow-Headers  |
-      | Access-Control-Expose-Headers |
-      | Access-Control-Allow-Origin   |
-      | Access-Control-Allow-Methods  |
-    #Then the following headers should be set
-    #  | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-    #  | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-    #  | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status |
-    #  | Access-Control-Allow-Origin   | https://aphno.badal |
-    #  | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT |
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /privatedata/getattribute                        | 997      | 401       |
-      | 2               | /privatedata/getattribute                        | 997      | 401       |
-      | 1               | /cloud/apps                                      | 997      | 401       |
-      | 2               | /cloud/apps                                      | 997      | 401       |
-      | 1               | /cloud/groups                                    | 997      | 401       |
-      | 2               | /cloud/groups                                    | 997      | 401       |
-      | 1               | /cloud/users                                     | 997      | 401       |
-      | 2               | /cloud/users                                     | 997      | 401       |
-
-    @files_external-app-required @notToImplementOnOCIS
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_external/api/v1/mounts               | 997      | 401       |
-      | 2               | /apps/files_external/api/v1/mounts               | 997      | 401       |
-
-    @files_sharing-app-required
-    Examples:
-      | ocs_api_version | endpoint                                         | ocs-code | http-code |
-      | 1               | /apps/files_sharing/api/v1/remote_shares         | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares         | 997      | 401       |
-      | 1               | /apps/files_sharing/api/v1/remote_shares/pending | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/remote_shares/pending | 997      | 401       |
-      | 1               | /apps/files_sharing/api/v1/shares                | 997      | 401       |
-      | 2               | /apps/files_sharing/api/v1/shares                | 997      | 401       |
-
-  @issue-34679
-  Scenario Outline: CORS headers should be returned when invalid password is used (admin only endpoints)
-    Given using OCS API version "<ocs_api_version>"
-    And the administrator has added "https://aphno.badal" to the list of personal CORS domains
-    And user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers using password "invalid"
-      | header | value               |
-      | Origin | https://aphno.badal |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the following headers should not be set
-      | header                        |
-      | Access-Control-Allow-Headers  |
-      | Access-Control-Expose-Headers |
-      | Access-Control-Allow-Origin   |
-      | Access-Control-Allow-Methods  |
-    #Then the following headers should be set
-    #  | header                        | value                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-    #  | Access-Control-Allow-Headers  | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With |
-    #  | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status |
-    #  | Access-Control-Allow-Origin   | https://aphno.badal |
-    #  | Access-Control-Allow-Methods  | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT |
-    Examples:
-      | ocs_api_version | endpoint      | ocs-code | http-code |
-      | 1               | /cloud/apps   | 997      | 401       |
-      | 2               | /cloud/apps   | 997      | 401       |
-      | 1               | /cloud/groups | 997      | 401       |
-      | 2               | /cloud/groups | 997      | 401       |
-      | 1               | /cloud/users  | 997      | 401       |
-      | 2               | /cloud/users  | 997      | 401       |

tests/acceptance/features/coreApiAuth/filesAppAuth.feature

@@ -1,40 +0,0 @@
-@api @notToImplementOnOCIS @issue-ocis-reva-28
-Feature: auth
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @smokeTest
-  Scenario: access files app anonymously
-    When a user requests "/index.php/apps/files" with "GET" and no authentication
-    Then the HTTP status code should be "401"
-
-  @smokeTest
-  Scenario: access files app with basic auth
-    When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth
-    Then the HTTP status code should be "200"
-
-  @smokeTest
-  Scenario: access files app with basic token auth
-    Given a new client token for "Alice" has been generated
-    When user "Alice" requests "/index.php/apps/files" with "GET" using basic token auth
-    Then the HTTP status code should be "200"
-
-  @smokeTest
-  Scenario: access files app with a client token
-    Given a new client token for "Alice" has been generated
-    When the user requests "/index.php/apps/files" with "GET" using the generated client token
-    Then the HTTP status code should be "200"
-
-  @smokeTest
-  Scenario: access files app with browser session
-    Given a new browser session for "Alice" has been started
-    When the user requests "/index.php/apps/files" with "GET" using the browser session
-    Then the HTTP status code should be "200"
-
-  @smokeTest
-  Scenario: access files app with an app password
-    Given a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    When the user requests "/index.php/apps/files" with "GET" using the generated app password
-    Then the HTTP status code should be "200"

tests/acceptance/features/coreApiAuth/tokenAuth.feature

@@ -1,61 +0,0 @@
-@api @notToImplementOnOCIS @issue-ocis-reva-28 @issue-ocis-reva-37
-Feature: tokenAuth
-
-  Background:
-    Given using OCS API version "1"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And token auth has been enforced
-
-
-  Scenario: creating a user with basic auth should be blocked when token auth is enforced
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-
-
-  Scenario: moving a file should be blocked when token auth is enforced
-    Given using new DAV path
-    When user "Alice" moves file "/textfile0.txt" to "/renamed_textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-  @smokeTest
-  Scenario: can access files app with an app password when token auth is enforced
-    Given a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    When the user requests "/index.php/apps/files" with "GET" using the generated app password
-    Then the HTTP status code should be "200"
-
-
-  Scenario: cannot access files app with an app password that is deleted when token auth is enforced
-    Given a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    And the user has deleted the app password named "my-client"
-    When the user requests "/index.php/apps/files" with "GET" using the generated app password
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Access files app with when there are multiple tokens generated
-    Given a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    And the user has generated a new app password named "my-new-client"
-    When the user requests "/index.php/apps/files" with "GET" using app password named "my-client"
-    Then the HTTP status code should be "200"
-    When the user requests "/index.php/apps/files" with "GET" using app password named "my-new-client"
-    Then the HTTP status code should be "200"
-
-  @smokeTest
-  Scenario: cannot access files app with basic auth when token auth is enforced
-    When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth
-    Then the HTTP status code should be "401"
-
-
-  Scenario: using WebDAV with basic auth should be blocked when token auth is enforced
-    When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic auth
-    Then the HTTP status code should be "401"
-
-  @files_sharing-app-required
-  Scenario: using OCS with basic auth should be blocked when token auth is enforced
-    When user "Alice" requests "/ocs/v1.php/apps/files_sharing/api/v1/remote_shares" with "GET" using basic auth
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"

tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature

@@ -1,29 +0,0 @@
-@api @files_sharing-app-required @notToImplementOnOCIS
-Feature: current oC10 behavior for issue-32068
-
-  @smokeTest @issue-32068 @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112
-  Scenario: send DELETE requests to OCS endpoints as admin with wrong password
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" requests these endpoints with "DELETE" using password "invalid" about user "Alice"
-      | endpoint                                                        |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/123         |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/123         |
-      | /ocs/v2.php/apps/files_sharing/api/v1/shares/123                |
-      | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123        |
-      | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123        |
-      | /ocs/v1.php/cloud/apps/testing                                  |
-      | /ocs/v2.php/cloud/apps/testing                                  |
-      | /ocs/v1.php/cloud/groups/group1                                 |
-      | /ocs/v2.php/cloud/groups/group1                                 |
-      | /ocs/v1.php/cloud/users/%username%                              |
-      | /ocs/v2.php/cloud/users/%username%                              |
-      | /ocs/v1.php/cloud/users/%username%/groups                       |
-      | /ocs/v2.php/cloud/users/%username%/groups                       |
-      | /ocs/v1.php/cloud/users/%username%/subadmins                    |
-      | /ocs/v2.php/cloud/users/%username%/subadmins                    |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"

tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature

@@ -1,90 +0,0 @@
-@api @files_external-app-required @notToImplementOnOCIS
-Feature: auth
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @issue-32068 @skipOnOcV10 @smokeTest
-  Scenario: using OCS anonymously
-    When a user requests these endpoints with "GET" and no authentication
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "401"
-
-  @issue-32068 @skipOnOcV10
-  Scenario: using OCS with non-admin basic auth
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"
-
-  @issue-32068 @skipOnOcV10 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112
-  Scenario: using OCS as normal user with wrong password
-    When user "Alice" requests these endpoints with "GET" using password "invalid"
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "401"
-
-
-  Scenario: using OCS as admin user with wrong password
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" requests these endpoints with "GET" using password "invalid"
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-
-
-  Scenario: using OCS with token auth of a normal user
-    Given a new client token for "Alice" has been generated
-    When user "Alice" requests these endpoints with "GET" using basic token auth
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When user "Alice" requests these endpoints with "GET" using basic token auth
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"
-
-
-  Scenario: using OCS with browser session of normal user
-    Given a new browser session for "Alice" has been started
-    When the user requests these endpoints with "GET" using a new browser session
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When the user requests these endpoints with "GET" using a new browser session
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"
-
-
-  Scenario: using OCS with an app password of a normal user
-    Given a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    When the user requests these endpoints with "GET" using the generated app password
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When the user requests these endpoints with "GET" using the generated app password
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"

tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature

@@ -1,38 +0,0 @@
-@api @notToImplementOnOCIS @files_external-app-required @issue-32068
-Feature: current oC10 behavior for issue-32068
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @smokeTest
-  Scenario: using OCS anonymously
-    When a user requests these endpoints with "GET" and no authentication
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"
-
-
-  Scenario: using OCS with non-admin basic auth
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"
-
-  @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112
-  Scenario: using OCS as normal user with wrong password
-    When user "Alice" requests these endpoints with "GET" using password "invalid"
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_external/api/v1/mounts               |
-      | /ocs/v2.php/apps/files_external/api/v1/mounts               |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"

tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature

@@ -1,91 +0,0 @@
-@api @notToImplementOnOCIS @files_sharing-app-required @issue-32068
-Feature: current oC10 behavior for issue-32068
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @issue-32068 @issue-ocis-reva-30 @smokeTest
-  Scenario: using OCS anonymously
-    When a user requests these endpoints with "GET" and no authentication
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v1.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v2.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v1.php/cloud/apps                                      |
-      | /ocs/v2.php/cloud/apps                                      |
-      | /ocs/v1.php/cloud/groups                                    |
-      | /ocs/v2.php/cloud/groups                                    |
-      | /ocs/v1.php/cloud/users                                     |
-      | /ocs/v2.php/cloud/users                                     |
-      | /ocs/v1.php/privatedata/getattribute                        |
-      | /ocs/v2.php/privatedata/getattribute                        |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"
-
-  @issue-32068 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @issue-ocis-reva-32 @issue-ocis-reva-33 @issue-ocis-reva-34 @issue-ocis-reva-35
-  Scenario: using OCS with non-admin basic auth
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v1.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v1.php/config                                          |
-      | /ocs/v1.php/privatedata/getattribute                        |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                                                    |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v2.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v2.php/config                                          |
-      | /ocs/v2.php/privatedata/getattribute                        |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"
-    When the user "Alice" requests these endpoints with "GET" with basic auth
-      | endpoint                 |
-      | /ocs/v1.php/cloud/apps   |
-      | /ocs/v1.php/cloud/groups |
-      | /ocs/v1.php/cloud/users  |
-      | /ocs/v2.php/cloud/apps   |
-      | /ocs/v2.php/cloud/groups |
-      | /ocs/v2.php/cloud/users  |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"
-
-  @issue-32068 @issue-ocis-reva-29 @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112
-  Scenario: using OCS as normal user with wrong password
-    When user "Alice" requests these endpoints with "GET" using password "invalid"
-      | endpoint                                                    |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares         |
-      | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
-      | /ocs/v1.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v2.php/apps/files_sharing/api/v1/shares                |
-      | /ocs/v1.php/cloud/apps                                      |
-      | /ocs/v2.php/cloud/apps                                      |
-      | /ocs/v1.php/cloud/groups                                    |
-      | /ocs/v2.php/cloud/groups                                    |
-      | /ocs/v1.php/cloud/users                                     |
-      | /ocs/v2.php/cloud/users                                     |
-      | /ocs/v1.php/privatedata/getattribute                        |
-      | /ocs/v2.php/privatedata/getattribute                        |
-    Then the HTTP status code of responses on all endpoints should be "401"
-    And the OCS status code of responses on all endpoints should be "997"
-    #And the OCS status code of responses on all endpoints should be "401"
-    When user "Alice" requests these endpoints with "GET" using password "invalid"
-      | endpoint           |
-      | /ocs/v1.php/config |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    When user "Alice" requests these endpoints with "GET" using password "invalid"
-      | endpoint           |
-      | /ocs/v2.php/config |
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "200"

tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature

@@ -1,13 +0,0 @@
-@api @files_sharing-app-required @notToImplementOnOCIS
-#When this issue is fixed, please delete this file and use the one from ocsPUTAuth.feature
-Feature: current oC10 behavior for issue-38423
-
-  Scenario: Request to edit nonexistent user by authorized admin gets unauthorized in http response
-      Given user "another-admin" has been created with default attributes and without skeleton files
-      And user "another-admin" has been added to group "admin"
-      When user "another-admin" requests these endpoints with "PUT" including body "doesnotmatter" about user "nonexistent"
-        | endpoint                                         |
-        | /ocs/v1.php/cloud/users/%username%               |
-        | /ocs/v2.php/cloud/users/%username%               |
-      Then the HTTP status code of responses on all endpoints should be "401"
-      And the OCS status code of responses on all endpoints should be "997"

tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature

@@ -1,28 +0,0 @@
-@api @skipOnOcis
-Feature: COPY file/folder
-
-  As a user
-  I want to copy a file or folder
-  So that I can duplicate it
-  
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-  
-
-  Scenario: send COPY requests to webDav endpoints with body as normal user
-    When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice"
-      | endpoint                                           |
-      | /remote.php/webdav/textfile0.txt                   |
-      | /remote.php/dav/files/%username%/textfile0.txt     |
-      | /remote.php/webdav/PARENT                          |
-      | /remote.php/dav/files/%username%/PARENT            |
-      | /remote.php/webdav/PARENT/parent.txt               |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-    Then the HTTP status code of responses on all endpoints should be "403"

tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature

@@ -1,35 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: usernames are case-insensitive in webDAV requests with app passwords
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-  @skipOnOcV10.10.0
-  Scenario: send PUT requests to webDav endpoints using app password token as password and lowercase of username
-    Given token auth has been enforced
-    And a new browser session for "Alice" has been started
-    And the user has generated a new app password named "my-client"
-    When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice"
-      | endpoint                                           |
-      | /remote.php/webdav/textfile0.txt                   |
-      | /remote.php/dav/files/%username%/textfile1.txt     |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-    Then the HTTP status code of responses on all endpoints should be "204"
-    When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice"
-      | endpoint                                 |
-      # this folder is created, so gives 201 - CREATED
-      | /remote.php/webdav/PARENS                |
-      | /remote.php/dav/files/%username%/FOLDERS |
-    Then the HTTP status code of responses on all endpoints should be "201"
-    When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice"
-      | endpoint                                |
-      # this folder already exists so gives 409 - CONFLICT
-      | /remote.php/dav/files/%username%/FOLDER |
-    Then the HTTP status code of responses on all endpoints should be "409"

tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature

@@ -1,24 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: delete file/folder
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-
-  Scenario: send DELETE requests to webDav endpoints with body as normal user
-    When user "Alice" requests these endpoints with "DELETE" including body "doesnotmatter" about user "Alice"
-      | endpoint                                           |
-      | /remote.php/webdav/textfile0.txt                   |
-      | /remote.php/dav/files/%username%/textfile1.txt     |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-      | /remote.php/webdav/PARENT                          |
-      | /remote.php/dav/files/%username%/FOLDER            |
-    Then the HTTP status code of responses on all endpoints should be "204"

tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature

@@ -1,30 +0,0 @@
-@api @skipOnOcis
-Feature: create folder using MKCOL
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-  Scenario: send MKCOL requests to another user's webDav endpoints as normal user
-    Given user "Brian" has been created with default attributes and without skeleton files
-    When user "Brian" requests these endpoints with "MKCOL" including body "" about user "Alice"
-      | endpoint                                        |
-      | /remote.php/dav/files/%username%/textfile0.txt  |
-      | /remote.php/dav/files/%username%/PARENT         |
-      | /remote.php/dav/files/%username%/does-not-exist |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-    Then the HTTP status code of responses on each endpoint should be "403, 403, 403, 409" respectively
-
-
-  Scenario: send MKCOL requests to non-existent user's webDav endpoints as normal user
-    Given user "Brian" has been created with default attributes and without skeleton files
-    When user "Brian" requests these endpoints with "MKCOL" including body "" about user "non-existent-user"
-      | endpoint                                                  |
-      | /remote.php/dav/files/non-existent-user/textfile0.txt     |
-      | /remote.php/dav/files/non-existent-user/PARENT            |
-      | /remote.php/dav/files/non-existent-user/does-not-exist    |
-      | /remote.php/dav/files/non-existent-user/PARENT/parent.txt |
-    Then the HTTP status code of responses on all endpoints should be "409"

tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature

@@ -1,24 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: MOVE file/folder
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-
-  Scenario: send MOVE requests to webDav endpoints with body as normal user
-    When user "Alice" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice"
-      | endpoint                                           |
-      | /remote.php/webdav/textfile0.txt                   |
-      | /remote.php/dav/files/%username%/textfile0.txt     |
-      | /remote.php/webdav/PARENT                          |
-      | /remote.php/dav/files/%username%/PARENT            |
-      | /remote.php/webdav/PARENT/parent.txt               |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-    Then the HTTP status code of responses on all endpoints should be "403"

tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature

@@ -1,23 +0,0 @@
-@api @issue-39597 @skipOnOcis
-Feature: get file info using PUT
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-
-  Scenario: send PUT requests to another user's webDav endpoints as normal user
-    When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice"
-      | endpoint                                       |
-      | /remote.php/dav/files/%username%/textfile1.txt |
-      | /remote.php/dav/files/%username%/PARENT        |
-    Then the HTTP status code of responses on all endpoints should be "403"
-    When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice"
-      | endpoint                                           |
-      | /remote.php/dav/files/%username%/PARENT/parent.txt |
-    Then the HTTP status code of responses on all endpoints should be "409"

tests/acceptance/features/coreApiComments/comments.feature

@@ -1,80 +0,0 @@
-@api @comments-app-required @issue-ocis-reva-38
-Feature: Comments
-
-  Background:
-    Given using new DAV path
-    And user "Alice" has been created with default attributes and without skeleton files
-
-  @smokeTest
-  Scenario: Getting info of comments using files endpoint
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt"
-    And user "Alice" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment          |
-      | Alice | My first comment |
-    When user "Alice" gets the following properties of folder "/myFileToComment.txt" using the WebDAV API
-      | propertyName       |
-      | oc:comments-href   |
-      | oc:comments-count  |
-      | oc:comments-unread |
-    Then the HTTP status code should be "201"
-    And the single response should contain a property "oc:comments-count" with value "1"
-    And the single response should contain a property "oc:comments-unread" with value "0"
-    And the single response should contain a property "oc:comments-href" with value "%a_comment_url%"
-
-
-  Scenario: Getting info on comments for a folder using the endpoint
-    Given user "Alice" has created folder "/PARENT"
-    And user "Alice" has commented with content "My first comment" on folder "/PARENT"
-    And user "Alice" should have the following comments on folder "/PARENT"
-      | user  | comment          |
-      | Alice | My first comment |
-    When user "Alice" gets the following properties of folder "/PARENT" using the WebDAV API
-      | propertyName       |
-      | oc:comments-href   |
-      | oc:comments-count  |
-      | oc:comments-unread |
-    Then the HTTP status code should be "201"
-    And the single response should contain a property "oc:comments-count" with value "1"
-    And the single response should contain a property "oc:comments-unread" with value "0"
-    And the single response should contain a property "oc:comments-href" with value "%a_comment_url%"
-
-
-  Scenario: Getting more info about comments using REPORT method
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt"
-    When user "Alice" gets all information about the comments on file "myFileToComment.txt" using the WebDAV REPORT API
-    Then the HTTP status code should be "201"
-    And the following comment properties should be listed about user "Alice"
-      | propertyName     | propertyValue    |
-      | verb             | comment          |
-      | actorType        | users            |
-      | actorId          | %username%       |
-      | objectType       | files            |
-      | isUnread         | false            |
-      | actorDisplayName | %displayname%    |
-      | message          | My first comment |
-
-
-  Scenario: Getting more info about comments using PROPFIND method
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has commented with content "My first comment" on file "myFileToComment.txt"
-    When user "Alice" gets the following comment properties of file "myFileToComment.txt" using the WebDAV PROPFIND API
-      | propertyName        |
-      | oc:verb             |
-      | oc:actorType        |
-      | oc:actorId          |
-      | oc:objectType       |
-      | oc:isUnread         |
-      | oc:actorDisplayName |
-      | oc:message          |
-    Then the HTTP status code should be success
-    And the following comment properties should be listed about user "Alice"
-      | propertyName     | propertyValue    |
-      | verb             | comment          |
-      | actorType        | users            |
-      | actorId          | %username%       |
-      | objectType       | files            |
-      | isUnread         | false            |
-      | actorDisplayName | %displayname%    |
-      | message          | My first comment |

tests/acceptance/features/coreApiComments/createComments.feature

@@ -1,106 +0,0 @@
-@api @comments-app-required @files_sharing-app-required @issue-ocis-reva-38
-Feature: Comments
-
-  Background:
-    Given using new DAV path
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-
-  @smokeTest
-  Scenario Outline: Creating a comment on a file belonging to myself
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    When user "Alice" comments with content "<comment>" on file "/myFileToComment.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment   |
-      | Alice | <comment> |
-    Examples:
-      | comment          |
-      | My first comment |
-      | 😀    🤖         |
-      | नेपालि           |
-
-
-  Scenario: Creating a comment on a shared file belonging to another user
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has shared file "/myFileToComment.txt" with user "Brian"
-    When user "Brian" comments with content "A comment from sharee" on file "/myFileToComment.txt" using the WebDAV API
-    And user "Alice" comments with content "A comment from sharer" on file "/myFileToComment.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Brian" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment               |
-      | Brian | A comment from sharee |
-      | Alice | A comment from sharer |
-
-
-  Scenario: sharee comments on a group shared file
-    Given group "grp1" has been created
-    And user "Brian" has been added to group "grp1"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has shared file "/myFileToComment.txt" with group "grp1"
-    When user "Brian" comments with content "Comment from sharee" on file "/myFileToComment.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment             |
-      | Brian | Comment from sharee |
-
-
-  Scenario: sharee comments on read-only shared file
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has created a share with settings
-      | path        | /myFileToComment.txt |
-      | shareType   | user                 |
-      | shareWith   | Brian                |
-      | permissions | read                 |
-    When user "Brian" comments with content "Comment from sharee" on file "/myFileToComment.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment             |
-      | Brian | Comment from sharee |
-
-
-  Scenario: sharee comments on upload-only shared folder
-    Given user "Alice" has created folder "/FOLDER_TO_SHARE"
-    And user "Alice" has created a share with settings
-      | path        | /FOLDER_TO_SHARE |
-      | shareType   | user             |
-      | shareWith   | Brian            |
-      | permissions | create           |
-    When user "Brian" comments with content "Comment from sharee" on folder "/FOLDER_TO_SHARE" using the WebDAV API
-    Then the HTTP status code should be "501"
-    And user "Alice" should have 0 comments on file "/FOLDER_TO_SHARE"
-
-
-  Scenario: Creating a comment on a folder belonging to myself
-    Given user "Alice" has created folder "/FOLDER"
-    When user "Alice" comments with content "My first comment" on folder "/FOLDER" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have the following comments on folder "/FOLDER"
-      | user  | comment          |
-      | Alice | My first comment |
-
-
-  Scenario: Creating a comment on a shared folder belonging to another user
-    Given user "Alice" has created folder "/FOLDER_TO_SHARE"
-    And user "Alice" has shared folder "/FOLDER_TO_SHARE" with user "Brian"
-    When user "Brian" comments with content "A comment from sharee" on folder "/FOLDER_TO_SHARE" using the WebDAV API
-    And user "Alice" comments with content "A comment from sharer" on folder "/FOLDER_TO_SHARE" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Brian" should have the following comments on file "/FOLDER_TO_SHARE"
-      | user  | comment               |
-      | Brian | A comment from sharee |
-      | Alice | A comment from sharer |
-
-
-  Scenario: sharee comments on a group shared folder
-    Given group "grp1" has been created
-    And user "Brian" has been added to group "grp1"
-    And user "Alice" has created folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with group "grp1"
-    When user "Brian" comments with content "Comment from sharee" on folder "/FOLDER_TO_COMMENT" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have the following comments on folder "/FOLDER_TO_COMMENT"
-      | user  | comment             |
-      | Brian | Comment from sharee |

tests/acceptance/features/coreApiComments/deleteComments.feature

@@ -1,110 +0,0 @@
-@api @comments-app-required @issue-ocis-reva-38
-Feature: Comments
-
-  Background:
-    Given using new DAV path
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-
-  @smokeTest
-  Scenario Outline: Deleting my own comments on a file belonging to myself
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has commented with content "<comment>" on file "/myFileToComment.txt"
-    When user "Alice" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Alice" should have 0 comments on file "/myFileToComment.txt"
-    Examples:
-      | comment          |
-      | My first comment |
-      | 😀 🤖            |
-      | नेपालि           |
-
-
-  Scenario: Deleting a comment on a file belonging to myself having several comments
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt"
-    And user "Alice" has commented with content "My second comment" on file "/myFileToComment.txt"
-    And user "Alice" has commented with content "My third comment" on file "/myFileToComment.txt"
-    And user "Alice" has commented with content "My fourth comment" on file "/myFileToComment.txt"
-    When user "Alice" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Alice" should have 3 comments on file "/myFileToComment.txt"
-
-  @files_sharing-app-required
-  Scenario: Deleting my own comments on a file shared by somebody else
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt"
-    And user "Alice" has shared file "/myFileToComment.txt" with user "Brian"
-    And user "Alice" has commented with content "File owner comment" on file "/myFileToComment.txt"
-    And user "Brian" has commented with content "Sharee comment" on file "/myFileToComment.txt"
-    And user "Brian" should have the following comments on file "/myFileToComment.txt"
-      | user  | comment            |
-      | Alice | File owner comment |
-      | Brian | Sharee comment     |
-    When user "Brian" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Brian" should have 1 comments on file "/myFileToComment.txt"
-
-
-  Scenario: Deleting my own comments on a folder belonging to myself
-    Given user "Alice" has created folder "/FOLDER_TO_COMMENT_AND_DELETE"
-    And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT_AND_DELETE"
-    When user "Alice" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Alice" should have 0 comments on folder "/FOLDER_TO_COMMENT_AND_DELETE"
-
-
-  Scenario: Deleting a comment on a folder belonging to myself having several comments
-    Given user "Alice" has created folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has commented with content "My second comment" on folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has commented with content "My third comment" on folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has commented with content "My fourth comment" on folder "/FOLDER_TO_COMMENT"
-    When user "Alice" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Alice" should have 3 comments on folder "/FOLDER_TO_COMMENT"
-
-  @files_sharing-app-required
-  Scenario: Deleting my own comments on a folder shared by somebody else
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with user "Brian"
-    And user "Alice" has commented with content "Folder owner comment" on folder "/FOLDER_TO_COMMENT"
-    And user "Brian" has commented with content "Sharee comment" on folder "/FOLDER_TO_COMMENT"
-    When user "Brian" deletes the last created comment using the WebDAV API
-    Then the HTTP status code should be "204"
-    And user "Brian" should have 1 comments on folder "/FOLDER_TO_COMMENT"
-
-
-  Scenario: deleting a folder removes existing comments on the folder
-    Given user "Alice" has created folder "/FOLDER_TO_DELETE"
-    When user "Alice" comments with content "This should be deleted" on folder "/FOLDER_TO_DELETE" using the WebDAV API
-    And user "Alice" deletes folder "/FOLDER_TO_DELETE" using the WebDAV API
-    And user "Alice" has created folder "/FOLDER_TO_DELETE"
-    Then the HTTP status code should be "201"
-    And user "Alice" should have 0 comments on folder "/FOLDER_TO_DELETE"
-
-  @files_sharing-app-required
-  Scenario: deleting a user does not remove the comment
-    Given user "Alice" has created folder "/FOLDER_TO_COMMENT"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with user "Brian"
-    And user "Brian" has commented with content "Comment from sharee" on folder "/FOLDER_TO_COMMENT"
-    When the administrator deletes user "Brian" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should have 1 comments on folder "/FOLDER_TO_COMMENT"
-    And user "Alice" should have the following comments on folder "/FOLDER_TO_COMMENT"
-      | user          | comment             |
-      | deleted_users | Comment from sharee |
-
-
-  Scenario: deleting a content owner deletes the comment
-    Given user "Alice" has created folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has commented with content "Comment from owner" on folder "/FOLDER_TO_COMMENT"
-    And user "Alice" has been deleted
-    And user "Alice" has been created with default attributes and without skeleton files
-    When user "Alice" creates folder "/FOLDER_TO_COMMENT" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And user "Alice" should have 0 comments on folder "/FOLDER_TO_COMMENT"

tests/acceptance/features/coreApiComments/editComments.feature

@@ -1,60 +0,0 @@
-@api @comments-app-required @issue-ocis-reva-38
-Feature: Comments
-
-  Background:
-    Given using new DAV path
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-
-  @smokeTest
-  Scenario Outline: Edit my own comments on a file belonging to myself
-    Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" has commented with content "File owner comment" on file "/textfile0.txt"
-    When user "Alice" edits the last created comment with content "<comment>" using the WebDAV API
-    Then the HTTP status code should be "207"
-    And user "Alice" should have the following comments on file "/textfile0.txt"
-      | user  | comment   |
-      | Alice | <comment> |
-    Examples:
-      | comment           |
-      | My edited comment |
-      | 😀 🤖             |
-      | नेपालि            |
-
-  @files_sharing-app-required
-  Scenario: Edit my own comments on a file shared by someone with me
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    And user "Brian" has commented with content "Sharee comment" on file "/textfile0.txt"
-    When user "Brian" edits the last created comment with content "My edited comment" using the WebDAV API
-    Then the HTTP status code should be "207"
-    And user "Brian" should have the following comments on file "/textfile0.txt"
-      | user  | comment           |
-      | Brian | My edited comment |
-
-  @files_sharing-app-required
-  Scenario: Editing comments of other users should not be possible
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    And user "Brian" has commented with content "Sharee comment" on file "/textfile0.txt"
-    And user "Alice" should have the following comments on file "/textfile0.txt"
-      | user  | comment        |
-      | Brian | Sharee comment |
-    When user "Alice" edits the last created comment with content "Edit the comment of another user" using the WebDAV API
-    Then the HTTP status code should be "403"
-    And user "Alice" should have the following comments on file "/textfile0.txt"
-      | user  | comment        |
-      | Brian | Sharee comment |
-
-
-  Scenario: Edit my own comments on a folder belonging to myself
-    Given user "Alice" has created folder "FOLDER"
-    And user "Alice" has commented with content "Folder owner comment" on folder "/FOLDER"
-    When user "Alice" edits the last created comment with content "My edited comment" using the WebDAV API
-    Then the HTTP status code should be "207"
-    And user "Alice" should have the following comments on folder "/FOLDER"
-      | user  | comment           |
-      | Alice | My edited comment |

tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature

@@ -1,66 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: current oC10 behavior for issue-33840
-
-  Background:
-    Given using OCS API version "1"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile2.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile3.txt"
-    And user "Alice" has uploaded file with content "some data" to "/textfile4.txt"
-    And user "Alice" has created folder "/FOLDER"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
-
-  @issue-33840 @issue-ocis-reva-39
-  Scenario Outline: Get favorited elements and limit count of entries
-    Given using <dav_version> DAV path
-    And user "Alice" has favorited element "/textfile0.txt"
-    And user "Alice" has favorited element "/textfile1.txt"
-    And user "Alice" has favorited element "/textfile2.txt"
-    And user "Alice" has favorited element "/textfile3.txt"
-    And user "Alice" has favorited element "/textfile4.txt"
-    When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API
-    #Then the search result should contain any "3" of these entries:
-    Then the HTTP status code should be "207"
-    And the search result should contain any "0" of these entries:
-      | /textfile0.txt |
-      | /textfile1.txt |
-      | /textfile2.txt |
-      | /textfile3.txt |
-      | /textfile4.txt |
-    Examples:
-      | dav_version |
-      | old         |
-      | new         |
-
-  @issue-33840 @issue-ocis-reva-39
-  Scenario Outline: Get favorited elements paginated in subfolder
-    Given using <dav_version> DAV path
-    And user "Alice" has created folder "/subfolder"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile0.txt"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile1.txt"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile2.txt"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile3.txt"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile4.txt"
-    And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile5.txt"
-    And user "Alice" has favorited element "/subfolder/textfile0.txt"
-    And user "Alice" has favorited element "/subfolder/textfile1.txt"
-    And user "Alice" has favorited element "/subfolder/textfile2.txt"
-    And user "Alice" has favorited element "/subfolder/textfile3.txt"
-    And user "Alice" has favorited element "/subfolder/textfile4.txt"
-    And user "Alice" has favorited element "/subfolder/textfile5.txt"
-    When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API
-    #Then the search result should contain any "3" of these entries:
-    Then the HTTP status code should be "207"
-    And the search result should contain any "0" of these entries:
-      | /subfolder/textfile0.txt |
-      | /subfolder/textfile1.txt |
-      | /subfolder/textfile2.txt |
-      | /subfolder/textfile3.txt |
-      | /subfolder/textfile4.txt |
-    Examples:
-      | dav_version |
-      | old         |
-      | new         |

tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature

@@ -1,98 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: propagation of etags between federated and local server
-
-  Background:
-    Given using OCS API version "1"
-    And using server "REMOTE"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "PARENT"
-    And using server "LOCAL"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Brian" has created folder "PARENT"
-
-
-  Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/PARENT (2)"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/PARENT (2)" of user "Alice" on server "REMOTE" should have changed
-
-  @issue-enterprise-2848
-  Scenario: Overwrite a federated shared folder as sharer propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    # After fixing issue-enterprise-2848, change the following step to "should have changed"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed
-    #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-  @issue-enterprise-2848
-  Scenario: Adding a file to a federated shared folder as sharer propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/lorem.txt" to "/PARENT/new-textfile.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    # After fixing issue-enterprise-2848, change the following step to "should have changed"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed
-    #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/PARENT (2)"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/PARENT (2)" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/PARENT"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Brian" on server "LOCAL" should have changed
-
-
-  Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/lorem.txt" to "/PARENT (2)/new-textfile.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Brian" on server "LOCAL" should have changed

tests/acceptance/features/coreApiFederationToRoot1/federated.feature

@@ -1,585 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: federated
-
-  Background:
-    Given using server "REMOTE"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And using server "LOCAL"
-    And user "Brian" has been created with default attributes and without skeleton files
-
-  @smokeTest
-  Scenario Outline: Federate share a file with another server
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | id                     | A_STRING          |
-      | item_type              | file              |
-      | item_source            | A_STRING          |
-      | share_type             | federated         |
-      | file_source            | A_STRING          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_STRING          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@REMOTE |
-      | share_with_displayname | %username%@REMOTE |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @smokeTest
-  Scenario Outline: Federate share a file with local server
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And using server "LOCAL"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Alice" sharing with user "Brian" should include
-      | id                     | A_STRING          |
-      | item_type              | file              |
-      | item_source            | A_STRING          |
-      | share_type             | federated         |
-      | file_source            | A_STRING          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_STRING          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@LOCAL  |
-      | share_with_displayname | %username%@LOCAL  |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee can see the pending share
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee requests information of only one share
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /textfile0.txt           |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /textfile0.txt           |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,read,update,delete |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee requests information of only one share before accepting it
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    When user "Brian" retrieves the information of the last pending federated cloud share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status>"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: sending a GET request to a pending federated share is not valid
-    Given using OCS API version "<ocs-api-version>"
-    When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending/12"
-    Then the HTTP status code should be "405"
-    And the body of the response should be empty
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sending a GET request to a nonexistent federated share
-    Given using OCS API version "<ocs-api-version>"
-    When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/9999999999"
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
-    Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 404        | 200         |
-      | 2               | 404        | 404         |
-
-
-  Scenario Outline: accept a pending federated share
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    When user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Reshare a federated shared file
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /textfile0.txt    |
-      | shareType   | user              |
-      | shareWith   | Carol             |
-      | permissions | share,read,update |
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Carol" should include
-      | id                     | A_STRING          |
-      | item_type              | file              |
-      | item_source            | A_STRING          |
-      | share_type             | user              |
-      | file_source            | A_STRING          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_STRING          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%        |
-      | share_with_displayname | %displayname%     |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient - local server shares - remote server receives
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And the content of file "/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient - remote server shares - local server receives
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has created folder "PARENT"
-    And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/PARENT/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient using old chunking
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads the following "3" chunks to "/textfile0.txt" with old chunking and using the WebDAV API
-      | number | content |
-      | 1      | AAAAA   |
-      | 2      | BBBBB   |
-      | 3      | CCCCC   |
-    Then the HTTP status code should be "201"
-    And the content of file "/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC"
-    And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient using old chunking
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads the following "3" chunks to "/PARENT/textfile0.txt" with old chunking and using the WebDAV API
-      | number | content |
-      | 1      | AAAAA   |
-      | 2      | BBBBB   |
-      | 3      | CCCCC   |
-    Then the HTTP status code should be "201"
-    And the content of file "/PARENT/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC"
-    And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Federated sharee deletes an accepted federated share
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" deletes the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And user "Brian" should not see the following elements
-      | /textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the response should contain 0 entries
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the response should contain 0 entries
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-31276 @skipOnOcV10
-  Scenario Outline: Federated sharee tries to delete an accepted federated share sending wrong password
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should see the following elements
-      | /textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /textfile0.txt           |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /textfile0.txt           |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,delete,update,read |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Federated sharee deletes a pending federated share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last pending federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And user "Brian" should not see the following elements
-      | /textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the response should contain 0 entries
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the response should contain 0 entries
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-31276 @skipOnOcV10
-  Scenario Outline: Federated sharee tries to delete a pending federated share sending wrong password
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should not see the following elements
-      | /textfile0.txt |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body
-    Given using OCS API version "<ocs-api-version>"
-    When user "UNAUTHORIZED_USER" requests shared secret using the federation API
-    Then the HTTP status code should be "<http-status>"
-    And the OCS status code should be "403"
-    Examples:
-      | ocs-api-version | http-status |
-      | 1               | 200         |
-      | 2               | 403         |
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on home storage
-    Given using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "201"
-    And as user "Alice" on server "REMOTE" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on remote storage - local server shares - remote server receives
-    Given the quota of user "Brian" has been set to "20 B"
-    And user "Brian" has created folder "PARENT"
-    And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on remote storage - remote server shares - local server receives
-    Given using server "REMOTE"
-    And the quota of user "Alice" has been set to "20 B"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-
-
-  Scenario Outline: share of a folder to a federated user who already has a folder with the same name
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/Alice"
-    And using server "LOCAL"
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/Brian"
-    When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING       |
-      | remote      | REMOTE         |
-      | name        | /zzzfolder     |
-      | owner       | %username%     |
-      | user        | %username%     |
-      | mountpoint  | /zzzfolder (2) |
-      | type        | dir            |
-      | permissions | all            |
-    And as "Brian" folder "zzzfolder/Brian" should exist
-    And as "Brian" folder "zzzfolder (2)/Alice" should exist
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: share of a file to the federated user who already has a file with the same name
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    When user "Alice" from server "REMOTE" shares "/randomfile.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /randomfile.txt          |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /randomfile (2).txt      |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,delete,update,read |
-    And the content of file "/randomfile.txt" for user "Brian" on server "LOCAL" should be "local content"
-    And the content of file "/randomfile (2).txt" for user "Brian" on server "LOCAL" should be "remote content"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-35154
-  Scenario: receive a local share that has the same name as a previously received federated share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/remote"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/local"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Carol" from server "LOCAL" using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Alice" from server "REMOTE" shares "randomfile.txt" with user "Carol" from server "LOCAL" using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Brian" shares folder "zzzfolder" with user "Carol" using the sharing API
-    And user "Brian" shares folder "randomfile.txt" with user "Carol" using the sharing API
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    # local shares are taking priority at the moment
-    And as "Carol" folder "zzzfolder (2)/remote" should exist
-    And as "Carol" folder "zzzfolder/local" should exist
-    And the content of file "/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content"
-    And the content of file "/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content"
-
-
-  Scenario: receive a federated share that has the same name as a previously received local share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/remote"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/local"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    When user "Brian" shares folder "zzzfolder" with user "Carol" using the sharing API
-    And user "Brian" shares folder "randomfile.txt" with user "Carol" using the sharing API
-    And user "Alice" from server "REMOTE" shares "zzzfolder" with user "Carol" from server "LOCAL" using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Alice" from server "REMOTE" shares "randomfile.txt" with user "Carol" from server "LOCAL" using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And as "Carol" folder "zzzfolder/local" should exist
-    And as "Carol" folder "zzzfolder (2)/remote" should exist
-    And the content of file "/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content"
-    And the content of file "/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content"

tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature

@@ -1,69 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: current oC10 behavior for issue-31276
-
-  Background:
-    Given using server "REMOTE"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And using server "LOCAL"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-
-  @issue-31276
-  Scenario Outline: Federated sharee tries to delete an accepted federated share sending wrong password
-    Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API
-    #Then the OCS status code should be "401"
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should see the following elements
-      | /textfile0 (2).txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /textfile0.txt           |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /textfile0 (2).txt       |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,delete,update,read |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-  @issue-31276
-  Scenario Outline: Federated sharee tries to delete a pending federated share sending wrong password
-    Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should not see the following elements
-      | /textfile0 (2).txt |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |

tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature

@@ -1,141 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: Save public shares created by oC users
-
-  Background:
-    Given using server "LOCAL"
-    And user "Alice" has been created with default attributes and without skeleton files
-
-
-  Scenario: Mount public share created from local server
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    When user "Brian" adds the public share created from server "LOCAL" using the sharing API
-    Then the HTTP status code should be "200"
-    And as "Brian" folder "/PARENT" should exist
-    And as "Brian" file "/PARENT/lorem.txt" should exist
-
-
-  Scenario: Mount public share and then delete (local server share)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT |
-      | permissions | read    |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Brian" deletes folder "/PARENT" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And as "Brian" folder "/PARENT" should not exist
-
-
-  Scenario Outline: Mount public share and sharer unshares the share (local server share)
-    Given using OCS API version "<ocs_api_version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT    |
-      | permissions | read       |
-      | name        | sharedlink |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Alice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
-    And the HTTP status code should be "200"
-    And as "Brian" folder "/PARENT" should not exist
-    Examples:
-      | ocs_api_version | ocs_status_code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: Mount public share and try to reshare (local server share)
-    Given using OCS API version "<ocs_api_version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path | PARENT |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-
-  Scenario: Mount public share created from remote server
-    Given using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And using server "LOCAL"
-    When user "Alice" adds the public share created from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "200"
-    And as "Alice" folder "/PARENT" should exist
-    And as "Alice" file "/PARENT/lorem.txt" should exist
-
-
-  Scenario: Mount public share and then delete (remote server share)
-    Given using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT |
-      | permissions | read    |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    When user "Alice" deletes folder "/PARENT" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And as "Alice" folder "/PARENT" should not exist
-
-
-  Scenario Outline: Mount public share and sharer unshares the share (remote server share)
-    Given using OCS API version "<ocs_api_version>"
-    And using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT    |
-      | permissions | read       |
-      | name        | sharedlink |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    When user "RemoteAlice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
-    And the HTTP status code should be "200"
-    When using server "LOCAL"
-    Then the HTTP status code should be "200"
-    And as "Alice" folder "/PARENT" should not exist
-    Examples:
-      | ocs_api_version | ocs_status_code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: Mount public share and try to reshare (remote server share)
-    Given using OCS API version "<ocs_api_version>"
-    And using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    When user "Alice" creates a public link share using the sharing API with settings
-      | path | PARENT |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |

tests/acceptance/features/coreApiFederationToRoot2/federated.feature

@@ -1,763 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: federated
-
-  Background:
-    Given using server "REMOTE"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And using server "LOCAL"
-    And user "Brian" has been created with default attributes and without skeleton files
-
-  @issue-35839 @skipOnOcV10
-  Scenario: "Auto accept from trusted servers" enabled with remote server
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on each endpoint should be "201, 100" respectively
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And as "Brian" file "textfile1 (2).txt" should exist
-    And url "%remote_server%" should be a trusted server
-
-  @issue-35839 @skipOnOcV10
-  Scenario: "Auto accept from trusted servers" disabled with remote server
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on each endpoint should be "201, 100" respectively
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And as "Brian" file "textfile1.txt" should not exist
-    And url "%remote_server%" should be a trusted server
-
-
-  Scenario: Federated share with "Auto add server" enabled
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "1"
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And as "Brian" file "textfile1.txt" should exist
-    And url "%remote_server%" should be a trusted server
-
-
-  Scenario: Federated share with "Auto add server" disabled
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And as "Brian" file "textfile1.txt" should exist
-    And url "%remote_server%" should not be a trusted server
-
-  @issue-35839 @skipOnOcV10
-  Scenario: enable "Add server automatically" once a federated share was created successfully
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And parameter "autoAddServers" of app "federation" has been set to "1"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And url "%remote_server%" should be a trusted server
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And as "Brian" file "textfile1.txt" should exist
-
-  @issue-35839 @skipOnOcV10
-  Scenario: disable "Add server automatically" once a federated share was created successfully
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And url "%remote_server%" should not be a trusted server
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And as "Brian" file "textfile1.txt" should not exist
-
-
-  Scenario Outline: federated share receiver sees the original content of a received file
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When using server "LOCAL"
-    Then the content of file "/file-to-share" for user "Brian" should be "thisContentIsVisible"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: federated share receiver sees the original content of a received file in multiple levels of folders
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentIsVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When using server "LOCAL"
-    Then the content of file "/file-to-share" for user "Brian" should be "thisContentIsVisible"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver adds files/folders in the federated share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/RandomFolder/new-file" using the WebDAV API
-    And user "Alice" creates folder "/RandomFolder/sub-folder" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/PARENT/RandomFolder/new-file" should exist
-    And as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should exist
-    And the content of file "/PARENT/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver adds files/folders in the federated share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" uploads file with content "thisContentIsFinal" to "/RandomFolder/new-file" using the WebDAV API
-    And user "Brian" creates folder "/RandomFolder/sub-folder" using the WebDAV API
-    And using server "REMOTE"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Alice" file "/PARENT/RandomFolder/new-file" should exist
-    And as "Alice" file "/PARENT/RandomFolder/file-to-share" should exist
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should exist
-    And the content of file "/PARENT/RandomFolder/new-file" for user "Alice" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver deletes files/folders of the received share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" deletes folder "/RandomFolder/sub-folder" using the WebDAV API
-    And user "Brian" deletes file "/RandomFolder/file-to-share" using the WebDAV API
-    And using server "REMOTE"
-    Then the HTTP status code of responses on all endpoints should be "204"
-    And as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Alice" folder "/PARENT/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver deletes files/folders of the received share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" deletes folder "/RandomFolder/sub-folder" using the WebDAV API
-    And user "Alice" deletes file "/RandomFolder/file-to-share" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "204"
-    And as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/PARENT/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver renames files/folders of the received share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" moves folder "/RandomFolder/sub-folder" to "/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Brian" moves file "/RandomFolder/file-to-share" to "/RandomFolder/renamedFile" using the WebDAV API
-    And using server "REMOTE"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist
-    But as "Alice" file "/PARENT/RandomFolder/renamedFile" should exist
-    And the content of file "/PARENT/RandomFolder/renamedFile" for user "Alice" should be "thisContentShouldBeVisible"
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Alice" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver renames files/folders of the received share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" moves folder "/RandomFolder/sub-folder" to "/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Alice" moves file "/RandomFolder/file-to-share" to "/RandomFolder/renamedFile" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist
-    But as "Brian" file "/PARENT/RandomFolder/renamedFile" should exist
-    And the content of file "/PARENT/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible"
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer modifies the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeChanged" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code should be "204"
-    And the content of file "/file-to-share" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer adds files/folders in the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/new-file" using the WebDAV API
-    And user "Alice" creates folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/RandomFolder/new-file" should exist
-    And as "Brian" file "/RandomFolder/file-to-share" should exist
-    And as "Brian" folder "/RandomFolder/sub-folder" should exist
-    And the content of file "/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer deletes files/folders of the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" deletes folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API
-    And user "Alice" deletes file "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "204"
-    And as "Brian" file "/RandomFolder/file-to-share" should not exist
-    And as "Brian" folder "/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer renames files/folders of the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" moves folder "/PARENT/RandomFolder/sub-folder" to "/PARENT/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Alice" moves file "/PARENT/RandomFolder/file-to-share" to "/PARENT/RandomFolder/renamedFile" using the WebDAV API
-    And using server "LOCAL"
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/RandomFolder/file-to-share" should not exist
-    But as "Brian" file "/RandomFolder/renamedFile" should exist
-    And the content of file "/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible"
-    And as "Brian" folder "/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer unshares the federated share and the receiver no longer sees the files/folders
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last share using the sharing API
-    And using server "REMOTE"
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code should be "200"
-    And as "Alice" file "/RandomFolder/file-to-share" should not exist
-    And as "Alice" folder "/RandomFolder" should not exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: federated share receiver can move the location of the received share and changes are correctly seen at both ends
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" creates folder "/CHILD" using the WebDAV API
-    And user "Alice" creates folder "/CHILD/newRandomFolder" using the WebDAV API
-    And user "Alice" moves folder "/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist
-    When using server "LOCAL"
-    Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist
-    When user "Brian" uploads file with content "thisIsTheContentOfNewFile" to "/PARENT/RandomFolder/newFile" using the WebDAV API
-    And user "Brian" uploads file with content "theContentIsChanged" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    And using server "REMOTE"
-    Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
-    And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist
-    And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Alice" should be "theContentIsChanged"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: federated sharer can move the location of the received share and changes are correctly seen at both ends
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" creates folder "/CHILD" using the WebDAV API
-    And user "Brian" creates folder "/CHILD/newRandomFolder" using the WebDAV API
-    And user "Brian" moves folder "PARENT/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist
-    When using server "REMOTE"
-    Then as "Alice" file "/RandomFolder/file-to-share" should exist
-    When user "Alice" uploads file with content "thisIsTheContentOfNewFile" to "/RandomFolder/newFile" using the WebDAV API
-    And user "Alice" uploads file with content "theContentIsChanged" to "/RandomFolder/file-to-share" using the WebDAV API
-    When using server "LOCAL"
-    Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
-    And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist
-    And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Brian" should be "theContentIsChanged"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Both Incoming and Outgoing federation shares are allowed
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API
-    And using server "REMOTE"
-    Then the OCS status code of responses on all endpoints should be "<ocs-status-code>"
-    And the HTTP status code of responses on all endpoints should be "200"
-    Then as "Alice" file "/file-to-share" should exist
-    And the content of file "/file-to-share" for user "Alice" should be "thisContentIsVisible"
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the OCS status code of responses on all endpoints should be "<ocs-status-code>"
-    And the HTTP status code of responses on each endpoint should be "201, 200, 200" respectively
-    And as "Brian" file "/newFile" should exist
-    And the content of file "/newFile" for user "Brian" should be "thisFileIsShared"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: Incoming federation shares are allowed but outgoing federation shares are restricted
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    Then the OCS status code should be "403"
-    And the HTTP status code should be "<http-status-code>"
-    And user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the OCS status code of responses on all endpoints should be "<ocs-status-code>"
-    And the HTTP status code of responses on each endpoint should be "201, 200, 200" respectively
-    And as "Brian" file "/newFile" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 200              |
-      | 2               | 200             | 403              |
-
-
-  Scenario Outline: Incoming federation shares are restricted but outgoing federation shares are allowed
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" from server "LOCAL" has shared "/file-to-share" with user "Alice" from server "REMOTE"
-    And using server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "403"
-    And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/newFile" should not exist
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 201, 200         |
-      | 2               | 201, 403         |
-
-
-  Scenario Outline: Both Incoming and outgoing federation shares are restricted
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads file with content "thisContentIsVisible" to "/file-to-share" using the WebDAV API
-    And user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    Then the OCS status code should be "403"
-    And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code should be "403"
-    And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/newFile" should not exist
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 201, 200         |
-      | 2               | 201, 403         |
-
-
-  Scenario Outline: Incoming and outgoing federation shares are enabled for local server but incoming federation shares are restricted for remote server
-    Given using server "REMOTE"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And using server "LOCAL"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads file with content "thisContentIsVisible" to "/file-to-share" using the WebDAV API
-    And user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    Then the OCS status code should be "403"
-    And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "<ocs-status-code>"
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then as "Brian" file "/newFile" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 201, 200         |
-      | 2               | 200             | 201, 403         |
-
-
-  Scenario Outline: Incoming and outgoing federation shares are enabled for local server but outgoing federation shares are restricted for remote server
-    Given using server "REMOTE"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And using server "LOCAL"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API
-    Then the OCS status code of responses on all endpoints should be "<ocs-status-code>"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And as "Alice" file "/file-to-share" should exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code should be "403"
-    And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/newFile" should not exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 201, 200         |
-      | 2               | 200             | 201, 403         |
-
-
-  Scenario Outline: Federated share a file with another server with expiration date
-    Given using OCS API version "<ocs-api-version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile1.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | id                     | A_NUMBER          |
-      | item_type              | file              |
-      | item_source            | A_NUMBER          |
-      | share_type             | federated         |
-      | file_source            | A_NUMBER          |
-      | path                   | /textfile1.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_NUMBER          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | file_parent            | A_NUMBER          |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@REMOTE |
-      | share_with_displayname | %username%@REMOTE |
-      | expiration             | +7 days           |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled but not enforced, user shares without specifying expireDate
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration |  |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-#      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares without specifying expireDate
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration | +7days |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date disabled
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "no"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration |  |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Expiration date is enforced for federated share, user modifies expiration date
-    Given using OCS API version "<ocs-api-version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Brian" updates the last share using the sharing API with
-      | expireDate | +3 days |
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration | +3 days |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares with expiration date more than the default
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Brian" updates the last share using the sharing API with
-      | expireDate | +10 days |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-
-  Scenario Outline: User modifies expiration date for federated reshare of a file with another server with default expiration date
-    Given using OCS API version "<ocs_api_version>"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and without skeleton files
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share"
-    When user "Carol" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Carol" updates the last share using the sharing API with
-      | expireDate | +3 days |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status>"
-    And the fields of the last response to user "Carol" sharing with user "Alice" should include
-      | expiration | +3 days |
-
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: User modifies expiration date more than the default for federated reshare of a file
-    Given using OCS API version "<ocs_api_version>"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and without skeleton files
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share"
-    When user "Carol" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Carol" updates the last share using the sharing API with
-      | expireDate | +10 days |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    And the information of the last share of user "Carol" should include
-      | expiration | +7 days |
-
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-  @skipOnFedOcV10.7 @skipOnFedOcV10.6
-  Scenario: set a federated user share to expire yesterday and verify that it is not accessible
-    Given using OCS API version "2"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" with expiry date of "+5 days"
-    And the administrator has expired the last created share using the testing API
-    And using server "LOCAL"
-    When user "Brian" gets the info of the last share using the sharing API
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "404"
-    And user "Brian" should not see the share id of the last share
-    And as "Brian" file "/textfile0.txt" should not exist
-    And using server "REMOTE"
-    And user "Alice" should not see the share id of the last share
-    And as "Alice" file "/textfile0.txt" should exist

tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature

@@ -1,75 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: current oC10 behavior for issue-35839
-
-  Background:
-    Given using server "REMOTE"
-    And user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-
-  @issue-35839
-  Scenario: "Auto accept from trusted servers" enabled with remote server
-    Given the trusted server list is cleared
-    # Remove this line once the issue is resolved
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on each endpoint should be "201, 100" respectively
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And as "Brian" file "textfile1 (2).txt" should exist
-    And url "%remote_server%" should be a trusted server
-
-  @issue-35839
-  Scenario: "Auto accept from trusted servers" disabled with remote server
-    Given the trusted server list is cleared
-    # Remove this line once the issue is resolved
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on each endpoint should be "201, 100" respectively
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And as "Brian" file "textfile1 (2).txt" should not exist
-    And url "%remote_server%" should be a trusted server
-
-  @issue-35839
-  Scenario: enable "Add server automatically" once a federated share was created successfully
-    Given parameter "autoAddServers" of app "federation" has been set to "1"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And url "%remote_server%" should be a trusted server
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    #Then as "Brian" file "textfile1 (2).txt" should exist
-    And as "Brian" file "textfile1 (2).txt" should not exist
-
-  @issue-35839
-  Scenario: disable "Add server automatically" once a federated share was created successfully
-    Given using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    And using server "LOCAL"
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And url "%remote_server%" should not be a trusted server
-    # Remove this line once the issue is resolved
-    When the administrator sets parameter "autoAddServers" of app "federation" to "0"
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And as "Brian" file "textfile1 (2).txt" should not exist

tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature

@@ -1,100 +0,0 @@
-@api @federation-app-required @files_sharing-app-required
-Feature: propagation of etags between federated and local server
-
-  Background:
-    Given using OCS API version "1"
-    And using server "REMOTE"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and without skeleton files
-    And using server "LOCAL"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Brian" has created folder "PARENT"
-
-  Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/Shares/PARENT"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/Shares/PARENT" of user "Alice" on server "REMOTE" should have changed
-
-  @issue-enterprise-2848
-  Scenario: Overwrite a federated shared folder as sharer propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    # After fixing issue-enterprise-2848, change the following step to "should have changed"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed
-    #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-  @issue-enterprise-2848
-  Scenario: Adding a file to a federated shared folder as sharer propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/lorem.txt" to "/PARENT/new-textfile.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    # After fixing issue-enterprise-2848, change the following step to "should have changed"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed
-    #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/Shares/PARENT"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/Shares/PARENT" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And user "Alice" has stored etag of element "/"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Alice" on server "REMOTE" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/PARENT"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed
-
-
-  Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Brian" on server "LOCAL" should have changed
-
-
-  Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer
-    Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Brian" has stored etag of element "/"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/lorem.txt" to "/Shares/PARENT/new-textfile.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the etag of element "/" of user "Brian" on server "LOCAL" should have changed

tests/acceptance/features/coreApiFederationToShares1/federated.feature

@@ -1,586 +0,0 @@
-@api @federation-app-required @files_sharing-app-required
-Feature: federated
-
-  Background:
-    Given using server "REMOTE"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and without skeleton files
-    And using server "LOCAL"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-
-  @smokeTest
-  Scenario Outline: Federate share a file with another server
-    Given using OCS API version "<ocs-api-version>"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | id                     | A_STRING          |
-      | item_type              | file              |
-      | item_source            | A_STRING          |
-      | share_type             | federated         |
-      | file_source            | A_STRING          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_STRING          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@REMOTE |
-      | share_with_displayname | %username%@REMOTE |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @smokeTest
-  Scenario Outline: Federate share a file with local server
-    Given using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Alice" sharing with user "Brian" should include
-      | id                     | A_STRING          |
-      | item_type              | file              |
-      | item_source            | A_STRING          |
-      | share_type             | federated         |
-      | file_source            | A_STRING          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_STRING          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@LOCAL  |
-      | share_with_displayname | %username%@LOCAL  |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee can see the pending share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee requests information of only one share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /textfile0.txt           |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /Shares/textfile0.txt    |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,read,update,delete |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee requests information of only one share before accepting it
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" retrieves the information of the last pending federated cloud share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status>"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: sending a GET request to a pending federated share is not valid
-    Given using OCS API version "<ocs-api-version>"
-    When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending/12"
-    Then the HTTP status code should be "405"
-    And the body of the response should be empty
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: sending a GET request to a nonexistent federated share
-    Given using OCS API version "<ocs-api-version>"
-    When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/9999999999"
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
-    Examples:
-      | ocs-api-version | ocs-status | http-status |
-      | 1               | 404        | 200         |
-      | 2               | 404        | 404         |
-
-
-  Scenario Outline: accept a pending federated share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Reshare a federated shared file
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" creates a share using the sharing API with settings
-      | path        | /Shares/textfile0.txt |
-      | shareType   | user                  |
-      | shareWith   | Carol                 |
-      | permissions | share,read,update     |
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Carol" should include
-      | id                     | A_STRING              |
-      | item_type              | file                  |
-      | item_source            | A_STRING              |
-      | share_type             | user                  |
-      | file_source            | A_STRING              |
-      | path                   | /Shares/textfile0.txt |
-      | permissions            | share,read,update     |
-      | stime                  | A_NUMBER              |
-      | storage                | A_STRING              |
-      | mail_send              | 0                     |
-      | uid_owner              | %username%            |
-      | displayname_owner      | %displayname%         |
-      | share_with             | %username%            |
-      | share_with_displayname | %displayname%         |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient - local server shares - remote server receives
-    Given user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And the content of file "/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient - remote server shares - local server receives
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives
-    Given user "Brian" has created folder "PARENT"
-    And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/PARENT/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives
-    Given using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a federated shared file as recipient using old chunking
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads the following "3" chunks to "/Shares/textfile0.txt" with old chunking and using the WebDAV API
-      | number | content |
-      | 1      | AAAAA   |
-      | 2      | BBBBB   |
-      | 3      | CCCCC   |
-    Then the HTTP status code should be "201"
-    And the content of file "/Shares/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC"
-    And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Overwrite a file in a federated shared folder as recipient using old chunking
-    Given using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" uploads the following "3" chunks to "/Shares/PARENT/textfile0.txt" with old chunking and using the WebDAV API
-      | number | content |
-      | 1      | AAAAA   |
-      | 2      | BBBBB   |
-      | 3      | CCCCC   |
-    Then the HTTP status code should be "201"
-    And the content of file "/Shares/PARENT/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC"
-    And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharee deletes an accepted federated share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And user "Brian" should not see the following elements
-      | /Shares/textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-31276 @skipOnOcV10
-  Scenario Outline: Federated sharee tries to delete an accepted federated share sending wrong password
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should see the following elements
-      | /Shares/textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /textfile0.txt           |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /Shares/textfile0.txt    |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,delete,update,read |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Federated sharee deletes a pending federated share
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last pending federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And user "Brian" should not see the following elements
-      | /Shares/textfile0.txt |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-31276 @skipOnOcV10
-  Scenario Outline: Federated sharee tries to delete a pending federated share sending wrong password
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL"
-    And using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should not see the following elements
-      | /Shares/textfile0.txt |
-    When user "Brian" gets the list of pending federated cloud shares using the sharing API
-    Then the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                                   |
-      | remote      | REMOTE                                     |
-      | remote_id   | A_STRING                                   |
-      | share_token | A_TOKEN                                    |
-      | name        | /textfile0.txt                             |
-      | owner       | %username%                                 |
-      | user        | %username%                                 |
-      | mountpoint  | {{TemporaryMountPointName#/textfile0.txt}} |
-      | accepted    | 0                                          |
-    When user "Brian" gets the list of federated cloud shares using the sharing API
-    Then the response should contain 0 entries
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body
-    Given using server "LOCAL"
-    And using OCS API version "<ocs-api-version>"
-    When user "UNAUTHORIZED_USER" requests shared secret using the federation API
-    Then the HTTP status code should be "<http-status>"
-    And the OCS status code should be "403"
-    Examples:
-      | ocs-api-version | http-status |
-      | 1               | 200         |
-      | 2               | 403         |
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on home storage
-    Given using server "REMOTE"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "201"
-    And as user "Alice" on server "REMOTE" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on remote storage - local server shares - remote server receives
-    Given using server "LOCAL"
-    And the quota of user "Brian" has been set to "20 B"
-    And user "Brian" has created folder "PARENT"
-    And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using server "REMOTE"
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-
-  @skipOnLDAP
-  Scenario: Upload file to received federated share while quota is set on remote storage - remote server shares - local server receives
-    Given using server "REMOTE"
-    And the quota of user "Alice" has been set to "20 B"
-    And user "Alice" has created folder "PARENT"
-    And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using server "LOCAL"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-
-
-  Scenario Outline: share of a folder to a federated user who already has a folder with the same name
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/Alice"
-    And using server "LOCAL"
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/Brian"
-    When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING          |
-      | remote      | REMOTE            |
-      | name        | /zzzfolder        |
-      | owner       | %username%        |
-      | user        | %username%        |
-      | mountpoint  | /Shares/zzzfolder |
-      | type        | dir               |
-      | permissions | all               |
-    And as "Brian" folder "zzzfolder/Brian" should exist
-    And as "Brian" folder "Shares/zzzfolder/Alice" should exist
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: share of a file to the federated user who already has a file with the same name
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    When user "Alice" from server "REMOTE" shares "/randomfile.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" retrieves the information of the last federated cloud share using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response about user "Alice" sharing with user "Brian" should include
-      | id          | A_STRING                 |
-      | remote      | REMOTE                   |
-      | remote_id   | A_STRING                 |
-      | share_token | A_TOKEN                  |
-      | name        | /randomfile.txt          |
-      | owner       | %username%               |
-      | user        | %username%               |
-      | mountpoint  | /Shares/randomfile.txt   |
-      | accepted    | 1                        |
-      | type        | file                     |
-      | permissions | share,delete,update,read |
-    And the content of file "/randomfile.txt" for user "Brian" on server "LOCAL" should be "local content"
-    And the content of file "/Shares/randomfile.txt" for user "Brian" on server "LOCAL" should be "remote content"
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-  @issue-35154
-  Scenario: receive a local share that has the same name as a previously received federated share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/remote"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/local"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    And user "Alice" from server "REMOTE" has shared "zzzfolder" with user "Carol" from server "LOCAL"
-    And user "Alice" from server "REMOTE" has shared "randomfile.txt" with user "Carol" from server "LOCAL"
-    And user "Brian" has shared folder "zzzfolder" with user "Carol"
-    And user "Brian" has shared folder "randomfile.txt" with user "Carol"
-    When user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Carol" accepts share "/zzzfolder" offered by user "Brian" using the sharing API
-    And user "Carol" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    # local shares are taking priority at the moment
-    And as "Carol" folder "/Shares/zzzfolder/remote" should exist
-    And as "Carol" folder "/Shares/zzzfolder (2)/local" should exist
-    And the content of file "/Shares/randomfile.txt" for user "Carol" on server "LOCAL" should be "remote content"
-    And the content of file "/Shares/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "local content"
-
-
-  Scenario: receive a federated share that has the same name as a previously received local share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/zzzfolder"
-    And user "Alice" has created folder "zzzfolder/remote"
-    And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt"
-    And using server "LOCAL"
-    And user "Carol" has been created with default attributes and small skeleton files
-    And user "Brian" has created folder "/zzzfolder"
-    And user "Brian" has created folder "zzzfolder/local"
-    And user "Brian" has uploaded file with content "local content" to "/randomfile.txt"
-    And user "Brian" has shared folder "zzzfolder" with user "Carol"
-    And user "Brian" has shared folder "randomfile.txt" with user "Carol"
-    And user "Alice" from server "REMOTE" has shared "zzzfolder" with user "Carol" from server "LOCAL"
-    And user "Alice" from server "REMOTE" has shared "randomfile.txt" with user "Carol" from server "LOCAL"
-    When user "Carol" accepts share "/zzzfolder" offered by user "Brian" using the sharing API
-    And user "Carol" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "100"
-    And as "Carol" folder "Shares/zzzfolder/local" should exist
-    And as "Carol" folder "Shares/zzzfolder (2)/remote" should exist
-    And the content of file "/Shares/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content"
-    And the content of file "/Shares/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content"

tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature

@@ -1,131 +0,0 @@
-@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS
-Feature: Save public shares created by oC users
-
-  Background:
-    Given using server "LOCAL"
-    And the administrator has set the default folder for received shares to "Shares"
-    And user "Alice" has been created with default attributes and without skeleton files
-
-
-  Scenario: Mount public share created from local server
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    When user "Brian" adds the public share created from server "LOCAL" using the sharing API
-    Then the HTTP status code should be "200"
-    And as "Brian" folder "/Shares/PARENT" should exist
-    And as "Brian" file "/Shares/PARENT/lorem.txt" should exist
-
-
-  Scenario: Mount public share and then delete (local server share)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT |
-      | permissions | read    |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Brian" deletes folder "/Shares/PARENT" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And as "Brian" folder "/Shares/PARENT" should not exist
-
-
-  Scenario: Mount public share and sharer unshares the share (local server share)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT    |
-      | permissions | read       |
-      | name        | sharedlink |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Alice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    And as "Brian" folder "/Shares/PARENT" should not exist
-
-
-  Scenario Outline: Mount public share and try to reshare (local server share)
-    Given using OCS API version "<ocs_api_version>"
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And user "Brian" has added the public share created from server "LOCAL" using the sharing API
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path | /Shares/PARENT |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-
-  Scenario: Mount public share created from remote server
-    Given using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And using server "LOCAL"
-    When user "Alice" adds the public share created from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "200"
-    And as "Alice" folder "/Shares/PARENT" should exist
-    And as "Alice" file "/Shares/PARENT/lorem.txt" should exist
-
-
-  Scenario: Mount public share and then delete (remote server share)
-    Given using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT |
-      | permissions | read    |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    When user "Alice" deletes folder "/Shares/PARENT" using the WebDAV API
-    Then the HTTP status code should be "204"
-    And as "Alice" folder "/Shares/PARENT" should not exist
-
-
-  Scenario: Mount public share and sharer unshares the share (remote server share)
-    Given using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT    |
-      | permissions | read       |
-      | name        | sharedlink |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    And using server "REMOTE"
-    When user "RemoteAlice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    When using server "LOCAL"
-    Then as "Alice" folder "/Shares/PARENT" should not exist
-
-
-  Scenario Outline: Mount public share and try to reshare (remote server share)
-    Given using OCS API version "<ocs_api_version>"
-    And using server "REMOTE"
-    And user "RemoteAlice" has been created with default attributes and without skeleton files
-    And user "RemoteAlice" has created folder "/PARENT"
-    And user "RemoteAlice" has created a public link share with settings
-      | path        | /PARENT                   |
-      | permissions | read,update,create,delete |
-    And using server "LOCAL"
-    And user "Alice" has added the public share created from server "REMOTE" using the sharing API
-    When user "Alice" creates a public link share using the sharing API with settings
-      | path | /Shares/PARENT |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |

tests/acceptance/features/coreApiFederationToShares2/federated.feature

@@ -1,761 +0,0 @@
-@api @federation-app-required @files_sharing-app-required
-Feature: federated
-
-  Background:
-    Given using server "REMOTE"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and without skeleton files
-    And using server "LOCAL"
-    And the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-
-
-  Scenario: "Auto accept from trusted servers" enabled with remote server
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    When using server "LOCAL"
-    Then as "Brian" file "Shares/textfile1.txt" should exist
-    And url "%remote_server%" should be a trusted server
-
-
-  Scenario: "Auto accept from trusted servers" disabled with remote server
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And the trusted server list is cleared
-    And using server "LOCAL"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
-    When the administrator adds url "%remote_server%" as trusted server using the testing API
-    And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the OCS status code should be "100"
-    And the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    When using server "LOCAL"
-    Then as "Brian" file "Shares/textfile1.txt" should not exist
-    And url "%remote_server%" should be a trusted server
-
-
-  Scenario: Federated share with "Auto add server" enabled
-    Given the trusted server list is cleared
-    And using server "LOCAL"
-    And parameter "autoAddServers" of app "federation" has been set to "1"
-    And using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be 200
-    And the OCS status code of responses on all endpoints should be "100"
-    When using server "LOCAL"
-    Then as "Brian" file "Shares/textfile1.txt" should exist
-    And url "%remote_server%" should be a trusted server
-
-
-  Scenario: Federated share with "Auto add server" disabled
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be 200
-    And the OCS status code of responses on all endpoints should be "100"
-    When using server "LOCAL"
-    Then as "Brian" file "Shares/textfile1.txt" should exist
-    And url "%remote_server%" should not be a trusted server
-
-  @issue-35839 @skipOnOcV10
-  Scenario: enable "Add server automatically" once a federated share was created successfully
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And parameter "autoAddServers" of app "federation" has been set to "1"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be 200
-    And the OCS status code of responses on all endpoints should be "100"
-    When using server "LOCAL"
-    Then url "%remote_server%" should be a trusted server
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    Then as "Brian" file "Shares/textfile1.txt" should exist
-
-
-  Scenario: disable "Add server automatically" once a federated share was created successfully
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
-    And using server "LOCAL"
-    And the trusted server list is cleared
-    And parameter "autoAddServers" of app "federation" has been set to "0"
-    And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes"
-    When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be 200
-    And the OCS status code of responses on all endpoints should be "100"
-    When using server "LOCAL"
-    Then url "%remote_server%" should not be a trusted server
-    When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    And as "Brian" file "Shares/textfile1.txt" should not exist
-
-
-  Scenario Outline: federated share receiver sees the original content of a received file
-    Given using server "REMOTE"
-    And user "Alice" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When using server "LOCAL"
-    Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsVisible"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: federated share receiver sees the original content of a received file in multiple levels of folders
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentIsVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When using server "LOCAL"
-    Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsVisible"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver adds files/folders in the federated share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/Shares/RandomFolder/new-file" using the WebDAV API
-    And user "Alice" creates folder "/Shares/RandomFolder/sub-folder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "LOCAL"
-    Then as "Brian" file "/PARENT/RandomFolder/new-file" should exist
-    And as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should exist
-    And the content of file "/PARENT/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver adds files/folders in the federated share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" uploads file with content "thisContentIsFinal" to "/Shares/RandomFolder/new-file" using the WebDAV API
-    And user "Brian" creates folder "/Shares/RandomFolder/sub-folder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "REMOTE"
-    Then as "Alice" file "/PARENT/RandomFolder/new-file" should exist
-    And as "Alice" file "/PARENT/RandomFolder/file-to-share" should exist
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should exist
-    And the content of file "/PARENT/RandomFolder/new-file" for user "Alice" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver deletes files/folders of the received share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" deletes folder "/Shares/RandomFolder/sub-folder" using the WebDAV API
-    And user "Brian" deletes file "/Shares/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 204
-    When using server "REMOTE"
-    Then as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Alice" folder "/PARENT/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver deletes files/folders of the received share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" deletes folder "/Shares/RandomFolder/sub-folder" using the WebDAV API
-    And user "Alice" deletes file "/Shares/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 204
-    When using server "LOCAL"
-    Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/PARENT/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: local federated share receiver renames files/folders of the received share
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "LOCAL"
-    When user "Brian" moves folder "/Shares/RandomFolder/sub-folder" to "/Shares/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Brian" moves file "/Shares/RandomFolder/file-to-share" to "/Shares/RandomFolder/renamedFile" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "REMOTE"
-    Then as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist
-    But as "Alice" file "/PARENT/RandomFolder/renamedFile" should exist
-    And the content of file "/PARENT/RandomFolder/renamedFile" for user "Alice" should be "thisContentShouldBeVisible"
-    And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Alice" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: remote federated share receiver renames files/folders of the received share
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" moves folder "/Shares/RandomFolder/sub-folder" to "/Shares/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Alice" moves file "/Shares/RandomFolder/file-to-share" to "/Shares/RandomFolder/renamedFile" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "LOCAL"
-    Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist
-    But as "Brian" file "/PARENT/RandomFolder/renamedFile" should exist
-    And the content of file "/PARENT/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible"
-    And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer modifies the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeChanged" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code should be "204"
-    When using server "LOCAL"
-    Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer adds files/folders in the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/new-file" using the WebDAV API
-    And user "Alice" creates folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "LOCAL"
-    Then as "Brian" file "/Shares/RandomFolder/new-file" should exist
-    And as "Brian" file "/Shares/RandomFolder/file-to-share" should exist
-    And as "Brian" folder "/Shares/RandomFolder/sub-folder" should exist
-    And the content of file "/Shares/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer deletes files/folders of the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" deletes folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API
-    And user "Alice" deletes file "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 204
-    When using server "LOCAL"
-    Then as "Brian" file "/Shares/RandomFolder/file-to-share" should not exist
-    And as "Brian" folder "/Shares/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/Shares/RandomFolder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer renames files/folders of the share which was shared to the federated share receiver
-    Given using server "REMOTE"
-    And user "Alice" has created folder "/PARENT"
-    And user "Alice" has created folder "/PARENT/RandomFolder"
-    And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder"
-    And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL"
-    And user "Brian" from server "LOCAL" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Alice" moves folder "/PARENT/RandomFolder/sub-folder" to "/PARENT/RandomFolder/renamed-sub-folder" using the WebDAV API
-    And user "Alice" moves file "/PARENT/RandomFolder/file-to-share" to "/PARENT/RandomFolder/renamedFile" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be 201
-    When using server "LOCAL"
-    Then as "Brian" file "/Shares/RandomFolder/file-to-share" should not exist
-    But as "Brian" file "/Shares/RandomFolder/renamedFile" should exist
-    And the content of file "/Shares/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible"
-    And as "Brian" folder "/Shares/RandomFolder/sub-folder" should not exist
-    But as "Brian" folder "/Shares/RandomFolder/renamed-sub-folder" should exist
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: sharer unshares the federated share and the receiver no longer sees the files/folders
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" deletes the last share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    When using server "REMOTE"
-    Then as "Alice" file "/Shares/RandomFolder/file-to-share" should not exist
-    And as "Alice" folder "/Shares/RandomFolder" should not exist
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: federated share receiver can move the location of the received share and changes are correctly seen at both ends
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    And using server "REMOTE"
-    When user "Alice" creates folder "/CHILD" using the WebDAV API
-    And user "Alice" creates folder "/CHILD/newRandomFolder" using the WebDAV API
-    And user "Alice" moves folder "/Shares/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist
-    When using server "LOCAL"
-    Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist
-    When user "Brian" uploads file with content "thisIsTheContentOfNewFile" to "/PARENT/RandomFolder/newFile" using the WebDAV API
-    And user "Brian" uploads file with content "theContentIsChanged" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
-    When using server "REMOTE"
-    Then as "Alice" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist
-    And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Alice" should be "theContentIsChanged"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: federated sharer can move the location of the received share and changes are correctly seen at both ends
-    Given user "Brian" has created folder "/PARENT"
-    And user "Brian" has created folder "/PARENT/RandomFolder"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share"
-    And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE"
-    And user "Alice" from server "REMOTE" has accepted the last pending share
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" creates folder "/CHILD" using the WebDAV API
-    And user "Brian" creates folder "/CHILD/newRandomFolder" using the WebDAV API
-    And user "Brian" moves folder "PARENT/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API
-    Then the HTTP status code of responses on all endpoints should be "201"
-    And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist
-    When using server "REMOTE"
-    Then as "Alice" file "/Shares/RandomFolder/file-to-share" should exist
-    When user "Alice" uploads file with content "thisIsTheContentOfNewFile" to "/Shares/RandomFolder/newFile" using the WebDAV API
-    And user "Alice" uploads file with content "theContentIsChanged" to "/Shares/RandomFolder/file-to-share" using the WebDAV API
-    Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
-    When using server "LOCAL"
-    Then as "Brian" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist
-    And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Brian" should be "theContentIsChanged"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-
-  Scenario Outline: Both Incoming and Outgoing federation shares are allowed
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And using OCS API version "<ocs-api-version>"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API
-    Then the HTTP status code of responses on all endpoints should be "200"
-    And the OCS status code of responses on all endpoints should be "<ocs-status-code>"
-    When using server "REMOTE"
-    Then as "Alice" file "/Shares/file-to-share" should exist
-    And the content of file "/Shares/file-to-share" for user "Alice" should be "thisContentIsVisible"
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And the OCS status code of responses on each endpoint should be "<ocs-status-code>" respectively
-    And using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then as "Brian" file "/Shares/newFile" should exist
-    And the content of file "/Shares/newFile" for user "Brian" should be "thisFileIsShared"
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: Incoming federation shares are allowed but outgoing federation shares are restricted
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    When using server "REMOTE"
-    Then user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/Shares/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "201, 200" respectively
-    And the OCS status code of responses on each endpoint should be "<ocs-status-code>" respectively
-    When using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And as "Brian" file "/Shares/newFile" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 200              |
-      | 2               | 200             | 403              |
-
-
-  Scenario Outline: Incoming federation shares are restricted but outgoing federation shares are allowed
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    When using server "REMOTE"
-    And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And as "Alice" file "/Shares/file-to-share" should exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And the OCS status code of responses on each endpoint should be "403" respectively
-    When using server "LOCAL"
-    Then user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/Shares/newFile" should not exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 201,200          |
-      | 2               | 200             | 201,403          |
-
-
-  Scenario Outline: Both Incoming and outgoing federation shares are restricted
-    Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    When using server "REMOTE"
-    Then user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/Shares/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "201,<http-status-code>" respectively
-    And the OCS status code of responses on each endpoint should be "403" respectively
-    When using server "LOCAL"
-    Then user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/Shares/newFile" should not exist
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 403              |
-
-
-  Scenario Outline: Incoming and outgoing federation shares are enabled for local server but incoming federation shares are restricted for remote server
-    Given using server "REMOTE"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And using server "LOCAL"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "403"
-    When using server "REMOTE"
-    Then user "Alice" should not have any pending federated cloud share
-    And as "Alice" file "/Shares/file-to-share" should not exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "201,200" respectively
-    And the OCS status code of responses on each endpoint should be "<ocs-status-code>" respectively
-    When using server "LOCAL"
-    And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And as "Brian" file "/Shares/newFile" should exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 200              |
-      | 2               | 200             | 403              |
-
-
-  Scenario Outline: Incoming and outgoing federation shares are enabled for local server but outgoing federation shares are restricted for remote server
-    Given using server "REMOTE"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no"
-    And using server "LOCAL"
-    And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes"
-    And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share"
-    And using OCS API version "<ocs-api-version>"
-    When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    When using server "REMOTE"
-    And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And as "Alice" file "/Shares/file-to-share" should exist
-    When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API
-    And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API
-    Then the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
-    And the OCS status code of responses on each endpoint should be "403" respectively
-    When using server "LOCAL"
-    Then user "Brian" should not have any pending federated cloud share
-    And as "Brian" file "/Shares/newFile" should not exist
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 100             | 201,200          |
-      | 2               | 200             | 201,403          |
-
-
-  Scenario Outline: Federated share a file with another server with expiration date
-    Given using OCS API version "<ocs-api-version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | id                     | A_NUMBER          |
-      | item_type              | file              |
-      | item_source            | A_NUMBER          |
-      | share_type             | federated         |
-      | file_source            | A_NUMBER          |
-      | path                   | /textfile0.txt    |
-      | permissions            | share,read,update |
-      | stime                  | A_NUMBER          |
-      | storage                | A_NUMBER          |
-      | mail_send              | 0                 |
-      | uid_owner              | %username%        |
-      | file_parent            | A_NUMBER          |
-      | displayname_owner      | %displayname%     |
-      | share_with             | %username%@REMOTE |
-      | share_with_displayname | %username%@REMOTE |
-      | expiration             | +7 days           |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled but not enforced, user shares without specifying expireDate
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration |  |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-#      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares without specifying expireDate
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration | +7days |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date disabled
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "no"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration |  |
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Expiration date is enforced for federated share, user modifies expiration date
-    Given using OCS API version "<ocs-api-version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE"
-    When user "Brian" updates the last share using the sharing API with
-      | expireDate | +3 days |
-    Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" sharing with user "Alice" should include
-      | expiration | +3 days |
-    Examples:
-      | ocs-api-version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: Federated sharing with default expiration date enabled and enforced, user updates the share with expiration date more than the default
-    Given using OCS API version "<ocs_api_version>"
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE"
-    When user "Brian" updates the last share using the sharing API with
-      | expireDate | +10 days |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-
-  Scenario Outline: User modifies expiration date for federated reshare of a file with another server with default expiration date
-    Given using OCS API version "<ocs_api_version>"
-    And user "Carol" has been created with default attributes and without skeleton files
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share"
-    And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian"
-    And user "Carol" from server "LOCAL" has shared "/Shares/textfile0.txt" with user "Alice" from server "REMOTE"
-    When user "Carol" updates the last share using the sharing API with
-      | expireDate | +3 days |
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status>"
-    And the fields of the last response to user "Carol" sharing with user "Alice" should include
-      | expiration | +3 days |
-
-    Examples:
-      | ocs_api_version | ocs-status |
-      | 1               | 100        |
-      | 2               | 200        |
-
-
-  Scenario Outline: User modifies expiration date more than the default for federated reshare of a file
-    Given using OCS API version "<ocs_api_version>"
-    And user "Carol" has been created with default attributes and without skeleton files
-    And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes"
-    And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7"
-    And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share"
-    And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian"
-    And user "Carol" from server "LOCAL" has shared "/Shares/textfile0.txt" with user "Alice" from server "REMOTE"
-    When user "Carol" updates the last share using the sharing API with
-      | expireDate | +10 days |
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "<http_status_code>"
-    And the information of the last share of user "Carol" should include
-      | expiration | +7 days |
-
-    Examples:
-      | ocs_api_version | http_status_code |
-      | 1               | 200              |
-      | 2               | 404              |

tests/acceptance/features/coreApiMain/appManagement.feature

@@ -1,61 +0,0 @@
-@api @skipOnLDAP @notToImplementOnOCIS
-Feature: AppManagement
-
-  Scenario: Update of patch version of an app
-    Given these apps' path has been configured additionally with following attributes:
-      | dir         | is_writable |
-      | apps-custom | true        |
-    And app "updatetest" with version "2.0.0" has been put in dir "apps"
-    And app "updatetest" has been enabled
-    And app "updatetest" has been disabled
-    When the administrator puts app "updatetest" with version "2.0.1" in dir "apps"
-    And the administrator enables app "updatetest"
-    Then the installed version of "updatetest" should be "2.0.1"
-
-
-  Scenario: Update of patch version of an app in apps-external, previous version in apps folder
-    Given these apps' path has been configured additionally with following attributes:
-      | dir         | is_writable |
-      | apps-custom | true        |
-    And app "updatetest" with version "2.0.0" has been put in dir "apps"
-    And app "updatetest" has been enabled
-    And app "updatetest" has been disabled
-    When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external"
-    And the administrator enables app "updatetest"
-    Then the installed version of "updatetest" should be "2.0.1"
-
-
-  Scenario: Update of patch version of an app in apps-external
-    Given these apps' path has been configured additionally with following attributes:
-      | dir         | is_writable |
-      | apps-custom | true        |
-    And app "updatetest" with version "2.0.0" has been put in dir "apps-external"
-    And app "updatetest" has been enabled
-    And app "updatetest" has been disabled
-    When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external"
-    And the administrator enables app "updatetest"
-    Then the installed version of "updatetest" should be "2.0.1"
-
-
-  Scenario: Update of patch version of an app but update is put in alternative folder
-    Given these apps' path has been configured additionally with following attributes:
-      | dir         | is_writable |
-      | apps-custom | true        |
-    And app "updatetest" with version "2.0.0" has been put in dir "apps"
-    And app "updatetest" has been enabled
-    And app "updatetest" has been disabled
-    When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom"
-    And the administrator enables app "updatetest"
-    Then the installed version of "updatetest" should be "2.0.1"
-
-
-  Scenario: Update of patch version of an app previously in apps-external but update is put in alternative folder
-    Given these apps' path has been configured additionally with following attributes:
-      | dir         | is_writable |
-      | apps-custom | true        |
-    And app "updatetest" with version "2.0.0" has been put in dir "apps-external"
-    And app "updatetest" has been enabled
-    And app "updatetest" has been disabled
-    When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom"
-    And the administrator enables app "updatetest"
-    Then the installed version of "updatetest" should be "2.0.1"

tests/acceptance/features/coreApiMain/caldav.feature

@@ -1,33 +0,0 @@
-@api
-Feature: caldav
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @caldav
-  Scenario: Accessing a nonexistent calendar of another user
-    When the administrator requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API
-    Then the CalDAV HTTP status code should be "404"
-    And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
-
-  @caldav
-  Scenario: Accessing a not shared calendar of another user
-    Given the administrator has successfully created a calendar named "MyCalendar"
-    When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API
-    Then the CalDAV HTTP status code should be "404"
-    And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
-
-  @caldav
-  Scenario: Accessing a nonexistent calendar of myself
-    When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API
-    Then the CalDAV HTTP status code should be "404"
-    And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
-
-  @caldav @smokeTest
-  Scenario: Creating a new calendar
-    Given user "Alice" has successfully created a calendar named "MyCalendar"
-    When user "Alice" requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API
-    Then the CalDAV HTTP status code should be "200"

tests/acceptance/features/coreApiMain/carddav.feature

@@ -1,33 +0,0 @@
-@api
-Feature: carddav
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  @carddav
-  Scenario: Accessing a nonexistent addressbook of another user
-    When the administrator requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API
-    Then the CardDAV HTTP status code should be "404"
-    And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
-
-  @carddav
-  Scenario: Accessing a not shared addressbook of another user
-    Given the administrator has successfully created an address book named "MyAddressbook"
-    When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API
-    Then the CardDAV HTTP status code should be "404"
-    And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
-
-  @carddav
-  Scenario: Accessing a nonexistent addressbook of myself
-    When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API
-    Then the CardDAV HTTP status code should be "404"
-    And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
-    And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
-
-  @carddav @smokeTest
-  Scenario: Creating a new addressbook
-    Given user "Alice" has successfully created an address book named "MyAddressbook"
-    When user "Alice" requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API
-    Then the CardDAV HTTP status code should be "200"

tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature

@@ -1,21 +0,0 @@
-@api @notToImplementOnOCIS
-Feature: checksums
-
-  Background:
-    Given user "Alice" has been created with default attributes and without skeleton files
-
-  # this is a bug demo scenario for https://github.com/owncloud/core/issues/38835
-  # Once this scenario is fixed Delete this file and remove @skipOnOcV10 tag from tests/acceptance/features/apiMain/checksums.feature:132
-  @files_sharing-app-required @skipOnStorage:ceph @skipOnStorage:scality
-  Scenario: Sharing and modifying a file should return correct checksum in the propfind using new DAV path
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And using new DAV path
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
-    And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
-    And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice"
-    And user "Brian" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt"
-    When user "Brian" requests the checksum of "/Shares/myChecksumFile.txt" via propfind
-    Then the HTTP status code should be "207"
-    And the webdav checksum should be empty

tests/acceptance/features/coreApiMain/external-storage.feature

@@ -1,114 +0,0 @@
-@api @local_storage @files_external-app-required @notToImplementOnOCIS
-Feature: external-storage
-
-  Background:
-    Given using OCS API version "1"
-    And using old DAV path
-
-  @public_link_share-feature-required @files_sharing-app-required
-  Scenario: Share by public link a file inside a local external storage
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has created folder "/local_storage/foo"
-    And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo/textfile0.txt"
-    And user "Alice" has shared folder "/local_storage/foo" with user "Brian"
-    When user "Brian" creates a public link share using the sharing API with settings
-      | path | foo |
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the fields of the last response to user "Brian" should include
-      | id       | A_NUMBER             |
-      | url      | AN_URL               |
-      | token    | A_TOKEN              |
-      | mimetype | httpd/unix-directory |
-
-
-  Scenario: Move a file into storage
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has created folder "/local_storage/foo1"
-    When user "Alice" moves file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Brian" file "/local_storage/foo1/textfile0.txt" should exist
-    And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist
-
-
-  Scenario: Move a file out of storage
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Alice" has created folder "/local_storage/foo2"
-    And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo2/textfile0.txt"
-    When user "Brian" moves file "/local_storage/foo2/textfile0.txt" to "/local.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Brian" file "/local_storage/foo2/textfile0.txt" should not exist
-    And as "Alice" file "/local_storage/foo2/textfile0.txt" should not exist
-    And as "Brian" file "/local.txt" should exist
-
-  @skipOnEncryptionType:user-keys
-  Scenario: Copy a file into storage
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-    And user "Alice" has created folder "/local_storage/foo1"
-    When user "Alice" copies file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist
-    And as "Alice" file "/textfile0.txt" should exist
-
-
-  Scenario: Copy a file out of storage
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-    And user "Alice" has created folder "/local_storage/foo1"
-    And user "Alice" has uploaded file with content "ownCloud test text file inside localstorage" to "/local_storage/foo1/fileInsideLocalStorage.txt"
-    When user "Alice" copies file "/local_storage/foo1/fileInsideLocalStorage.txt" to "/fileInsideLocalStorage.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Alice" file "/fileInsideLocalStorage.txt" should exist
-    And as "Alice" file "/local_storage/foo1/fileInsideLocalStorage.txt" should exist
-
-
-  Scenario: Download a file that exists in filecache but not storage fails with 404
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has created folder "/local_storage/foo3"
-    And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo3/textfile0.txt"
-    And file "foo3/textfile0.txt" has been deleted from local storage on the server
-    When user "Alice" downloads file "local_storage/foo3/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "404"
-    # See issue-37723 for discussion. In this case the server still reports the file exists
-    # in the folder. The file cache will be cleared after the local storage is scanned.
-    And as "Alice" file "local_storage/foo3/textfile0.txt" should exist
-
-
-  Scenario: Upload a file to external storage while quota is set on home storage
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And the quota of user "Alice" has been set to "1 B"
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/local_storage/testquota.txt" with all mechanisms using the WebDAV API
-    Then the HTTP status code of all upload responses should be "201"
-    And as "Alice" the files uploaded to "/local_storage/testquota.txt" with all mechanisms should exist
-
-
-  Scenario Outline: query OCS endpoint for information about the mount
-    Given using OCS API version "<ocs_api_version>"
-    And user "Alice" has been created with default attributes and small skeleton files
-    When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>"
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    And the fields of the last response to user "Alice" should include
-      | id          | A_NUMBER      |
-      | name        | local_storage |
-      | type        | dir           |
-      | backend     | Local         |
-      | scope       | system        |
-      | permissions | read          |
-      | class       | local         |
-    Examples:
-      | ocs_api_version | endpoint                           | ocs-code | http-code |
-      | 1               | /apps/files_external/api/v1/mounts | 100      | 200       |
-      | 2               | /apps/files_external/api/v1/mounts | 200      | 200       |

tests/acceptance/features/coreApiMain/quota.feature

@@ -1,393 +0,0 @@
-@api @issue-ocis-reva-101 @skipOnGraph
-Feature: quota
-
-  Background:
-    Given using OCS API version "1"
-    And user "Alice" has been created with default attributes and without skeleton files
-
-    # Owner
-
-  Scenario: Uploading a file as owner having enough quota (except new chunking)
-    Given the quota of user "Alice" has been set to "10 MB"
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "201"
-
-  @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Uploading a file as owner having enough quota (new chunking)
-    Given the quota of user "Alice" has been set to "10 MB"
-    And using new DAV path
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "201"
-
-  @smokeTest
-  Scenario: Uploading a file as owner having insufficient quota (except new chunking)
-    Given the quota of user "Alice" has been set to "10 B"
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-    And as "Alice" the files uploaded to "/testquota.txt" with all mechanisms except new chunking should not exist
-
-  @smokeTest @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Uploading a file as owner having insufficient quota (new chunking)
-    Given the quota of user "Alice" has been set to "10 B"
-    And using new DAV path
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "507"
-    And as "Alice" file "/testquota.txt" should not exist
-
-
-  Scenario: Overwriting a file as owner having enough quota (except new chunking)
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And the quota of user "Alice" has been set to "10 MB"
-    When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be between "201" and "204"
-
-  @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a file as owner having enough quota (new chunking)
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And the quota of user "Alice" has been set to "10 MB"
-    And using new DAV path
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be between "201" and "204"
-
-
-  Scenario: Overwriting a file as owner having insufficient quota (except new chunking)
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And the quota of user "Alice" has been set to "10 B"
-    When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-
-  @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a file as owner having insufficient quota (new chunking)
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And the quota of user "Alice" has been set to "10 B"
-    And using new DAV path
-    When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-
-	# Received shared folder
-
-  @files_sharing-app-required
-  Scenario: Uploading a file in received folder having enough quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "201"
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Uploading a file in received folder having enough quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "201"
-
-  @files_sharing-app-required
-  Scenario: Uploading a file in received folder having insufficient quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-    And as "Brian" the files uploaded to "/testquota/testquota.txt" with all mechanisms except new chunking should not exist
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Uploading a file in a received folder having insufficient quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "507"
-    And as "Brian" file "/testquota/testquota.txt" should not exist
-
-  @files_sharing-app-required
-  Scenario: Overwriting a file in received folder having enough quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be between "201" and "204"
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a file in received folder having enough quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be between "201" and "204"
-
-  @files_sharing-app-required
-  Scenario: Overwriting a file in received folder having insufficient quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-    And the content of file "/testquota/testquota.txt" for user "Alice" should be "test"
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a file in received folder having insufficient quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has created folder "/testquota"
-    And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
-    And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the content of file "/testquota/testquota.txt" for user "Alice" should be "test"
-
-	# Received shared file
-
-  @files_sharing-app-required
-  Scenario: Overwriting a received file having enough quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be between "201" and "204"
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a received file having enough quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
-    And the quota of user "Brian" has been set to "10 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be between "201" and "204"
-
-  @files_sharing-app-required
-  Scenario: Overwriting a received file having insufficient quota (except new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
-    Then the HTTP status code of all upload responses should be "507"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-
-  @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
-  Scenario: Overwriting a received file having insufficient quota (new chunking)
-    Given user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    And using new DAV path
-    When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-
-
-  Scenario: User with zero quota cannot upload a file
-    Given the quota of user "Alice" has been set to "0 B"
-    When user "Alice" uploads file with content "uploaded content" to "testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-
-
-  Scenario: User with zero quota can create a folder
-    Given the quota of user "Alice" has been set to "0 B"
-    When user "Alice" creates folder "testQuota" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Alice" folder "testQuota" should exist
-
-  @files_sharing-app-required
-  Scenario: user cannot create file on shared folder by a user with zero quota
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "0 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Brian" has created folder "shareFolder"
-    And user "Brian" has shared file "/shareFolder" with user "Alice"
-    And user "Alice" has accepted share "/shareFolder" offered by user "Brian"
-    When user "Alice" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-    And as "Brian" file "/shareFolder/newTextFile.txt" should not exist
-
-  @files_sharing-app-required
-  Scenario: share receiver with 0 quota should not be able to move file from shared folder to home folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "0 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian"
-    And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
-    When user "Brian" moves file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-
-  @files_sharing-app-required
-  Scenario: sharer should be able to upload to a folder shared with user having zero quota
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "0 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has created folder "shareFolder"
-    And user "Alice" has uploaded file with content "test" to "/shareFolder/testquota.txt"
-    And user "Alice" has shared file "/shareFolder" with user "Brian"
-    And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
-    When user "Alice" moves file "/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-    And as "Brian" file "/Shares/testquota" should not exist
-
-  @files_sharing-app-required
-  Scenario: share receiver with 0 quota should be able to upload on shared folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "0 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has created folder "shareFolder"
-    And user "Alice" has shared file "/shareFolder" with user "Brian"
-    And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
-    When user "Brian" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And the content of file "/shareFolder/newTextFile.txt" for user "Alice" should be "uploaded content"
-
-
-  Scenario: User should retain their old files even if their quota is set to 0
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And the quota of user "Alice" has been set to "0 B"
-    Then the content of file "/testquota.txt" for user "Alice" should be "test"
-
-
-  Scenario: User should be able to restore their deleted file when their quota is set to zero
-    Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
-    And user "Alice" has deleted file "/testquota.txt"
-    And the quota of user "Alice" has been set to "0 B"
-    When user "Alice" restores the file with original path "/testquota.txt" to "/testquota.txt" using the trashbin API
-    Then the HTTP status code should be "201"
-    And the content of file "/testquota.txt" for user "Alice" should be "test"
-
-  @files_sharing-app-required @skipOnOcV10.10
-  Scenario: share receiver with 0 quota can copy empty file from shared folder to home folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "0 B"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has created folder "shareFolder"
-    And user "Alice" has uploaded file with content "" to "/shareFolder/testquota.txt"
-    And user "Alice" has shared folder "/shareFolder" with user "Brian"
-    And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
-    When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Brian" file "testquota.txt" should exist
-
-
-  Scenario: User with zero quota can upload an empty file
-    Given the quota of user "Alice" has been set to "0 B"
-    When user "Alice" uploads file with content "" to "testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "201"
-    And as "Alice" file "testquota.txt" should exist
-
-  @files_sharing-app-required @skipOnOcV10.10
-  Scenario Outline: share receiver with insufficient quota should not be able to copy received shared file to home folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "<quota>"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has uploaded file with content "<file-content>" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian"
-    And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
-    When user "Brian" copies file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-    And as "Brian" file "/testquota.txt" should not exist
-    Examples:
-      | quota | file-content    |
-      | 0 B   | four            |
-      | 10 B  | test-content-15 |
-
-  @files_sharing-app-required @skipOnOcV10.10
-  Scenario Outline: share receiver with insufficient quota should not be able to copy file from shared folder to home folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "<quota>"
-    And the quota of user "Alice" has been set to "10 MB"
-    And user "Alice" has created folder "shareFolder"
-    And user "Alice" has uploaded file with content "<file-content>" to "/shareFolder/testquota.txt"
-    And user "Alice" has shared folder "/shareFolder" with user "Brian"
-    And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
-    When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-    And as "Brian" file "/testquota.txt" should not exist
-    Examples:
-      | quota | file-content    |
-      | 0 B   | four            |
-      | 10 B  | test-content-15 |
-
-  @files_sharing-app-required @skipOnOcV10.10 @skipOnEncryption @issue-encryption-357
-  Scenario: share receiver of a share with insufficient quota should not be able to copy from home folder to the received shared file
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    And user "Alice" has uploaded file with content "short" to "/testquota.txt"
-    And user "Brian" has uploaded file with content "longer line of text" to "/testquota.txt"
-    And user "Alice" has shared file "/testquota.txt" with user "Brian"
-    And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
-    When user "Brian" copies file "/testquota.txt" to "/Shares/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-    And as "Brian" file "/Shares/testquota.txt" should exist
-    And as "Alice" file "/testquota.txt" should exist
-    # The copy should have failed, so Alice should still see the original content
-    And the content of file "/testquota.txt" for user "Alice" should be "short"
-
-  @files_sharing-app-required @skipOnOcV10.10
-  Scenario: share receiver of a share with insufficient quota should not be able to copy file from home folder to the received shared folder
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Brian" has been created with default attributes and without skeleton files
-    And the quota of user "Brian" has been set to "10 MB"
-    And the quota of user "Alice" has been set to "10 B"
-    And user "Alice" has created folder "shareFolder"
-    And user "Alice" has shared folder "/shareFolder" with user "Brian"
-    And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
-    And user "Brian" has uploaded file with content "test-content-15" to "/testquota.txt"
-    When user "Brian" copies file "/testquota.txt" to "/Shares/shareFolder/testquota.txt" using the WebDAV API
-    Then the HTTP status code should be "507"
-    And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
-    And as "Brian" file "/testquota.txt" should exist
-    # The copy should have failed, so Alice should not see the file
-    And as "Alice" file "/shareFolder/testquota.txt" should not exist

tests/acceptance/features/coreApiMain/userSync.feature

@@ -1,68 +0,0 @@
-@api @notToImplementOnOCIS @issue-ocis-1241
-Feature: Users sync
-
-  Background:
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-
-
-  Scenario Outline: Trying to sync a user when there is no external user backend
-    Given using OCS API version "<ocs-api-version>"
-    When the administrator tries to sync user "Alice" using the OCS API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "<ocs-status-code>"
-    And the OCS status message should be ""
-    Examples:
-      | ocs-api-version | ocs-status-code |
-      | 1               | 100             |
-      | 2               | 200             |
-
-
-  Scenario Outline: Trying to sync a user which does not exist
-    Given using OCS API version "<ocs-api-version>"
-    When the administrator tries to sync user "nonexistentuser" using the OCS API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "404"
-    And the OCS status message should be "User is not known in any user backend: nonexistentuser"
-    Examples:
-      | ocs-api-version | http-status-code |
-      | 1               | 200              |
-      | 2               | 404              |
-
-
-  Scenario Outline: Trying to sync a user as another user which does not exist
-    Given using OCS API version "<ocs-api-version>"
-    When user "nonexistentuser" tries to sync user "Brian" using the OCS API
-    Then the HTTP status code should be "401"
-    And the OCS status code should be "997"
-    And the OCS status message should be "Unauthorised"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |
-
-  @smokeTest
-  Scenario Outline: Trying to sync a user by non admin user
-    Given using OCS API version "<ocs-api-version>"
-    When user "Alice" tries to sync user "Brian" using the OCS API
-    Then the HTTP status code should be "<http-status-code>"
-    And the OCS status code should be "<ocs-status-code>"
-    And the OCS status message should be "Logged in user must be an admin"
-    Examples:
-      | ocs-api-version | ocs-status-code | http-status-code |
-      | 1               | 403             | 200              |
-      | 2               | 403             | 403              |
-
-
-  Scenario Outline: Trying to sync a user by admin using an incorrect password
-    Given using OCS API version "<ocs-api-version>"
-    When the administrator tries to sync user "Brian" using password "invalid" and the OCS API
-    Then the HTTP status code should be "401"
-    And the OCS status code should be "997"
-    And the OCS status message should be "Unauthorised"
-    Examples:
-      | ocs-api-version |
-      | 1               |
-      | 2               |

tests/acceptance/features/coreApiProvisioning-v1/addUser.feature

@@ -1,224 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: add user
-  As an admin
-  I want to be able to add users
-  So that I can give people controlled individual access to resources on the ownCloud server
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin creates a user
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should exist
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario: admin creates a user with special characters in the username
-    Given the following users have been deleted
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username | password |
-      | a@-+_.b  | %alt1%   |
-      | a space  | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: admin tries to create an existing user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-
-  Scenario: admin tries to create an existing disabled user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And user "brand-new-user" has been disabled
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-  @notToImplementOnOCIS
-  Scenario: Admin creates a new user and adds him directly to a group
-    Given group "brand-new-group" has been created
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should belong to group "brand-new-group"
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario: admin creates a user and specifies a password with special characters
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username        | password                     | comment                               |
-      | brand-new-user1 | !@#$%^&*()-_+=[]{}:;,.<>?~/\ | special characters                    |
-      | brand-new-user2 | España§àôœ€                  | special European and other characters |
-      | brand-new-user3 | नेपाली                         | Unicode                               |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username        |
-      | brand-new-user1 |
-      | brand-new-user2 |
-      | brand-new-user3 |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username        |
-      | brand-new-user1 |
-      | brand-new-user2 |
-      | brand-new-user3 |
-
-
-  Scenario: admin creates a user and specifies an invalid password, containing just space
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password " " using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not exist
-
-
-  Scenario: admin creates a user and specifies a password containing spaces
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password "spaces in my password" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should exist
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario Outline: admin creates a user with username that contains capital letters
-    When the administrator sends a user creation request for user "<display-name>" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Brand-New-User" should exist
-    And user "BRAND-NEW-USER" should exist
-    And user "brand-new-user" should exist
-    And user "brand-NEW-user" should exist
-    And user "BrAnD-nEw-UsEr" should exist
-    And the display name of user "brand-new-user" should be "<display-name>"
-    Examples:
-      | display-name   |
-      | Brand-New-User |
-      | BRAND-NEW-USER |
-      | brand-new-user |
-      | brand-NEW-user |
-      | BrAnD-nEw-UsEr |
-
-
-  Scenario: admin tries to create an existing user but with username containing capital letters
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator sends a user creation request for user "BRAND-NEW-USER" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-
-  Scenario: admin creates a user with unusual username
-    Given the following users have been deleted
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username | password |
-      | user-1   | %alt1%   |
-      | null     | %alt1%   |
-      | nil      | %alt1%   |
-      | 123      | %alt1%   |
-      | -123     | %alt1%   |
-      | 0.0      | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to create a new user
-    Given user "brand-new-user" has been deleted
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When unauthorized user "subadmin" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API
-    Then the OCS status code should be "106"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not exist
-
-
-  Scenario: normal user should not be able to create another user
-    Given user "brand-new-user" has been deleted
-    And user "Alice" has been created with default attributes and without skeleton files
-    When unauthorized user "Alice" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API
-    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
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When the groupadmin "subadmin" sends a user creation request for user "brand-new-user" password "%alt1%" group "group101" using the provisioning API
-    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
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And group "group102" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When the groupadmin "subadmin" tries to create new user "brand-new-user" password "%alt1%" in other group "group102" using the provisioning API
-    Then the OCS status code should be "105"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not exist
-
-  @sqliteDB
-  Scenario: admin tries to create user with brackets in the username
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username  | password |
-      | [user1]   | %alt1%   |
-      | [ user2 ] | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "101"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not exist
-      | username  |
-      | [user1]   |
-      | [ user2 ] |

tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature

@@ -1,79 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: access user provisioning API using app password
-  As an ownCloud user
-  I want to be able to use the provisioning API with an app password
-  So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password.
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: admin deletes the user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And a new client token for the administrator has been generated
-    And a new browser session for the administrator has been started
-    And the user has generated a new app password named "my-client"
-    When the user requests "/ocs/v1.php/cloud/users/brand-new-user" with "DELETE" using the generated app password
-    Then the HTTP status code should be "200"
-    And user "brand-new-user" should not exist
-
-  @notToImplementOnOCIS
-  Scenario: subadmin gets users in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And user "another-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"
-    And a new client token for "brand-new-user" has been generated
-    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 HTTP status code should be "200"
-    And the users returned by the API should be
-      | another-new-user |
-
-  @smokeTest
-  Scenario: normal user gets their own information using the app password
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | brand-new-user | New User    |
-    And a new client token for "brand-new-user" has been generated
-    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/brand-new-user" with "GET" using the generated app password
-    Then the HTTP status code should be "200"
-    And the display name returned by the API should be "New User"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to get users of other group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "another-new-user" has been added to group "another-new-group"
-    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
-    And a new client token for "brand-new-user" has been generated
-    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 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:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And a new client token for "brand-new-user" has been generated
-    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/another-new-user" with "GET" using the generated app password
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature

@@ -1,61 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: create a subadmin
-  As an admin
-  I want to be able to make a user the subadmin of a group
-  So that I can give administrative privilege of a group to a user
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin creates a subadmin
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    When the administrator makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should be a subadmin of group "brand-new-group"
-
-
-  Scenario: admin tries to create a subadmin using a user which does not exist
-    Given user "nonexistentuser" has been deleted
-    And group "brand-new-group" has been created
-    When the administrator makes user "nonexistentuser" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And user "nonexistentuser" should not be a subadmin of group "brand-new-group"
-
-
-  Scenario: admin tries to create a subadmin using a group which does not exist
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "not-group" has been deleted
-    When the administrator makes user "brand-new-user" a subadmin of group "not-group" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-
-  Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "subadmin" makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "brand-new-user" should not be a subadmin of group "brand-new-group"
-
-
-  Scenario: normal user should not be able to make another user a subadmin
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And group "group101" has been created
-    When user "Alice" makes user "Brian" a subadmin of group "group101" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should not be a subadmin of group "group101"

tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature

@@ -1,134 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: delete users
-  As an admin
-  I want to be able to delete users
-  So that I can remove user from ownCloud
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: Delete a user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator deletes 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 user "brand-new-user" should not exist
-
-
-  Scenario: Delete a user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    When the administrator deletes the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not exist
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: Delete a user, and specify the user name in different case
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator deletes 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 user "brand-new-user" should not exist
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin deletes a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    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"
-    When user "subadmin" deletes 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 user "brand-new-user" should not exist
-
-
-  Scenario: normal user tries to delete a user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" deletes user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should exist
-
-
-  Scenario: administrator deletes another admin user
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | another-admin |
-    And user "another-admin" has been added to group "admin"
-    When the administrator deletes user "another-admin" using the provisioning API
-    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:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    And user "another-subadmin" has been added to group "new-group"
-    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" deletes user "another-subadmin" using the provisioning API
-    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:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    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" deletes user "another-subadmin" using the provisioning API
-    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:
-      | username      |
-      | subadmin      |
-      | another-admin |
-    And user "another-admin" has been added to group "admin"
-    And group "new-group" has been created
-    And user "another-admin" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" deletes user "another-admin" using the provisioning API
-    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:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" deletes user "brand-new-user" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "brand-new-user" should exist

tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature

@@ -1,36 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: disable an app
-  As an admin
-  I want to be able to disable an enabled app
-  So that I can stop the app features being used
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: Admin disables an app
-    Given app "comments" has been enabled
-    When the administrator disables app "comments"
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And app "comments" should be disabled
-
-
-  Scenario: subadmin tries to disable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been enabled
-    When user "subadmin" disables app "comments"
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled
-
-
-  Scenario: normal user tries to disable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been enabled
-    When user "brand-new-user" disables app "comments"
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled

tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature

@@ -1,311 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: disable user
-  As an admin
-  I want to be able to disable a user
-  So that I can remove access to files and resources for a user, without actually deleting the files and resources
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin disables an user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-
-
-  Scenario: admin disables an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    When the administrator disables the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should be disabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: Subadmin should be able to disable an user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable an user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And group "another-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "Alice" has been added to group "another-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | subadmin      |
-      | another-admin |
-    And group "brand-new-group" has been created
-    And user "another-admin" has been added to group "admin"
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "another-admin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-admin" should be enabled
-
-
-  Scenario: Admin can disable another admin user
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When the administrator disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "another-admin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Admin can disable subadmins in the same group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And the administrator has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When the administrator disables user "subadmin" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "subadmin" should be disabled
-
-
-  Scenario: Admin user cannot disable himself
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And user "another-admin" should be enabled
-
-
-  Scenario: disable an user with a regular user
-    Given these users have been created with default attributes and small skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" disables user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable himself
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "subadmin" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And user "subadmin" should be enabled
-
-  @smokeTest
-  Scenario: Making a web request with a disabled user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files"
-    Then the HTTP status code should be "403"
-
-
-  Scenario: Disabled user tries to download file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" downloads file "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to upload file
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" uploads file with content "uploaded content" to "newTextFile.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to rename file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" moves file "/textfile0.txt" to "/renamedTextfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to move file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" moves file "/textfile0.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to delete file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" deletes file "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to share a file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to share a folder
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: getting shares shared by disabled user (to shares folder)
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" file "/Shares/textfile0.txt" should exist
-    And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line
-
-  @notToImplementOnOCIS
-  Scenario: getting shares shared by disabled user (to root)
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" file "/textfile0.txt" should exist
-    And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line
-
-
-  Scenario: getting shares shared by disabled user in a group (to shares folder)
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And group "group0" has been created
-    And user "Brian" has been added to group "group0"
-    And user "Alice" has shared folder "/PARENT" with group "group0"
-    And user "Brian" has accepted share "/PARENT" offered by user "Alice"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" folder "/Shares/PARENT" should exist
-    And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line
-
-  @notToImplementOnOCIS
-  Scenario: getting shares shared by disabled user in a group (to root)
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And group "group0" has been created
-    And user "Brian" has been added to group "group0"
-    And user "Alice" has shared folder "/PARENT" with group "group0"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" folder "/PARENT" should exist
-    And the content of file "/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line
-
-
-  Scenario: Disabled user tries to create public link share
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" creates a public link share using the sharing API with settings
-      | path | textfile0.txt |
-    Then the HTTP status code should be "401"
-
-
-  Scenario Outline: getting public link share shared by disabled user using the new public WebDAV API
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has created a public link share with settings
-      | path        | /textfile0.txt |
-      | permissions | read           |
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And the public should be able to download the last publicly shared file using the <dav_version> public WebDAV API without a password and the content should be "ownCloud test text file 0" plus end-of-line
-    Examples:
-      | dav_version |
-      | old         |
-      | new         |
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should be able to disable user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "another-subadmin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be enabled
-
-
-  Scenario: normal user cannot disable himself
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    When user "Alice" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be enabled

tests/acceptance/features/coreApiProvisioning-v1/editUser.feature

@@ -1,369 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: edit users
-  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: the administrator can edit a user email
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 "100"
-    And the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  Scenario Outline: the administrator can edit a user email of an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username   | email   |
-      | <username> | <email> |
-    When the administrator changes the email of user "<username>" to "a-different-email@example.com" using the provisioning API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    And the email address of user "<username>" should be "a-different-email@example.com"
-    Examples:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-
-  @smokeTest
-  Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display")
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator changes the display 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 the display name of user "brand-new-user" should be "A New User"
-
-
-  Scenario: the administrator can edit a user display name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 the display name of user "brand-new-user" should be "A New User"
-
-
-  Scenario: the administrator can clear a user display name and then it defaults to the username
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And the administrator has changed the display name of user "brand-new-user" to "A New User"
-    When the administrator changes the display name of user "brand-new-user" to "" using the provisioning API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "100"
-    And the display name of user "brand-new-user" should be "brand-new-user"
-
-  @smokeTest
-  Scenario: the administrator can edit a user quota
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 "100"
-    And the quota definition of user "brand-new-user" should be "12 MB"
-
-
-  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"
-    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"
-    And the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  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"
-    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"
-    And the email address of user "brand-new-user" should be ""
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: a subadmin should be able to edit the user information in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    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"
-    When user "subadmin" changes the quota of user "brand-new-user" to "12MB" using the provisioning API
-    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
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 |
-    And the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  Scenario Outline: a normal user should be able to change their display name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When user "brand-new-user" changes the display name of user "brand-new-user" to "<display-name>" 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 | <display-name> |
-    And the display name of user "brand-new-user" should be "<display-name>"
-    Examples:
-      | display-name    |
-      | Alan Border     |
-      | Phil Cyclist 🚴 |
-
-
-  Scenario: a normal user should not be able to change their quota
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 |
-    And the quota definition of user "brand-new-user" should be "default"
-
-  @notToImplementOnOCIS
-  Scenario: the administrator can edit user information with admin permissions
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | 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
-    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
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    And user "another-subadmin" has been added to group "new-group"
-    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
-    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
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    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
-    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"
-
-
-  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
-
-
-  Scenario: Admin gives access to users to change their email address
-    Given user "Alice" has been created with default attributes and without skeleton files
-    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
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  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
-    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
-      | email | alice@example.org |
-    And the email address of user "Alice" should not have changed
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, admin can still change the email address
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean"
-    When the administrator 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
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, admin can still change their own email address
-    Given the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean"
-    When the administrator changes the email of user "admin" to "something@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 "admin" returned by the API should include
-      | email | something@example.com |
-    And the email address of user "admin" should be "something@example.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, subadmin can still change the email address of a user they are subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "Alice" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean"
-    When user "subadmin" 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
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, subadmin cannot change the email address of a user they are not subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice
-    And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean"
-    When user "subadmin" 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
-      | email | alice@example.org |
-    And the email address of user "Alice" should not have changed
-
-
-  Scenario: Admin gives access to users to change their display name
-    Given user "Alice" has been created with default attributes and without skeleton files
-    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
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  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
-    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
-      | displayname | Alice Hansen |
-    And the display name of user "Alice" should not have changed
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, admin can still change display name
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean"
-    When the administrator changes the display name 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
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, admin can still change their own display name
-    Given the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean"
-    When the administrator changes the display name of user "admin" to "The Administrator" 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 "admin" returned by the API should include
-      | displayname | The Administrator |
-    And the display name of user "admin" should be "The Administrator"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, subadmin can still change the display name of a user they are subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "Alice" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean"
-    When user "subadmin" changes the display name 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"
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, subadmin cannot change the display name of a user they are not subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice
-    And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean"
-    When user "subadmin" 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
-      | displayname | Alice Hansen |
-    And the display name of user "Alice" should not have changed

tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature

@@ -1,37 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: enable an app
-  As an admin
-  I want to be able to enable a disabled app
-  So that I can use the app features again
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: Admin enables an app
-    Given app "comments" has been disabled
-    When the administrator enables app "comments"
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And app "comments" should be enabled
-    And the information for app "comments" should have a valid version
-
-
-  Scenario: subadmin tries to enable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been disabled
-    When user "subadmin" enables app "comments"
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled
-
-
-  Scenario: normal user tries to enable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been disabled
-    When user "brand-new-user" enables app "comments"
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled

tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature

@@ -1,172 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: enable user
-  As an admin
-  I want to be able to enable a user
-  So that I can give a user access to their files and resources again if they are now authorized for that
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin enables an user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When the administrator enables user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-
-  Scenario: admin enables an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    And the following users have been disabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    When the administrator enables the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should be enabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: admin enables another admin user
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    And user "another-admin" has been disabled
-    When the administrator enables user "another-admin" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "another-admin" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: admin enables subadmins in the same group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And the administrator has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been disabled
-    When the administrator enables user "subadmin" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "subadmin" should be enabled
-
-
-  Scenario: admin tries to enable himself
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    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 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:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Brian" has been disabled
-    When user "Alice" tries to enable user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to enable himself
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been disabled
-    When user "subadmin" tries to enable user "subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "subadmin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Making a web request with an enabled user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files"
-    Then the HTTP status code should be "200"
-
-
-  Scenario: normal user should not be able to enable himself
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    And user "Alice" has been disabled
-    When user "Alice" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be disabled
-
-
-  Scenario: subadmin should be able to enable user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-
-  Scenario: subadmin should not be able to enable user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be disabled
-
-
-  Scenario: subadmin should be able to enable user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-
-  Scenario: subadmin should not be able to enable another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username            |
-      | subadmin            |
-      | another-subadmin    |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been disabled
-    When user "subadmin" tries to enable user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be disabled

tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature

@@ -1,19 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get app info
-  As an admin
-  I want to be able to get app info
-  So that I can get the information of a specific application
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin gets app info
-    When the administrator gets the info of app "files"
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the XML "data" "id" value should be "files"
-    And the XML "data" "name" value should be "Files"
-    And the XML "data" "types" "element" value should be "filesystem"
-    And the XML "data" "dependencies" "owncloud" "min-version" attribute value should be a valid version string
-    And the XML "data" "dependencies" "owncloud" "max-version" attribute value should be a valid version string

tests/acceptance/features/coreApiProvisioning-v1/getApps.feature

@@ -1,87 +0,0 @@
-@api @provisioning_api-app-required @files_sharing-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get apps
-  As an admin
-  I want to be able to get the list of apps on my ownCloud
-  So that I can manage apps
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @comments-app-required @files_trashbin-app-required @files_versions-app-required @systemtags-app-required
-  Scenario: admin gets enabled apps
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments             |
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | files_trashbin       |
-      | files_versions       |
-      | provisioning_api     |
-      | systemtags           |
-      | updatenotification   |
-
-
-  Scenario: admin gets enabled apps - check for the minimal list of apps
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-
-  @comments-app-required
-  Scenario: admin gets enabled apps when some app is disabled
-    Given app "comments" has been disabled
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-    And the apps returned by the API should not include
-      | comments |
-
-  @comments-app-required
-  Scenario: admin gets disabled apps
-    Given app "comments" has been disabled
-    When the administrator gets all disabled apps using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments |
-    And the apps returned by the API should not include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-
-  @comments-app-required
-  Scenario: admin gets all apps
-    Given app "comments" has been disabled
-    When the administrator gets all apps using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments             |
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_external       |
-      | files_sharing        |
-      | updatenotification   |

tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature

@@ -1,55 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get subadmins
-  As an admin
-  I want to be able to get the list of subadmins of a group
-  So that I can manage subadmins of a group
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin gets subadmin users of a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 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
-    And group "nonexistentgroup" has been deleted
-    When the administrator gets all the subadmins of group "nonexistentgroup" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-
-  Scenario: subadmin tries to get other subadmins of the same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" gets all the subadmins of group "brand-new-group" 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 the subadmins of the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "brand-new-user" gets all the subadmins of group "brand-new-group" 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

tests/acceptance/features/coreApiProvisioning-v1/getUser.feature

@@ -1,193 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get 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 an existing user
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | brand-new-user | 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"
-    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
-
-
-  Scenario Outline: admin gets an existing user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username   | displayname   | email   |
-      | <username> | <displayname> | <email> |
-    When the administrator retrieves the information of user "<username>" 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 "<displayname>"
-    And the email address returned by the API should be "<email>"
-    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:
-      | username | displayname  | email               |
-      | a@-+_.b  | A weird b    | a.b@example.com     |
-      | a space  | A Space Name | a.space@example.com |
-
- 
-  Scenario: admin gets an existing user, providing uppercase username in the URL
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | brand-new-user | 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"
-    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
-
-
-  Scenario: admin tries to get a nonexistent user
-    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 @notToImplementOnOCIS
-  Scenario: a subadmin gets information of a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | subadmin       | Sub Admin   |
-      | brand-new-user | New User    |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    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 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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin tries to get information of a user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "brand-new-user" 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: a normal user tries to get information of another user
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "another-new-user" retrieves the information of user "brand-new-user" 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: a normal user gets their own information
-    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
-
- 
-  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 "<username1>" retrieves the information of user "<username2>" 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 |
-
- 
-  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 "<username1>" retrieves the information of user "<username2>" 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 |
-
- 
-  Scenario: admin gets information of a user with admin permissions
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | Alice          | Admin Alice    |
-    And user "Alice" has been added to group "admin"
-    When the administrator retrieves the information of user "Alice" 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 "Admin Alice"
-    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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "another-subadmin" 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 "Regular 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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should not be able to get information of another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "another-subadmin" 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

tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature

@@ -1,53 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get users
-  As an admin
-  I want to be able to list the users that exist
-  So that I can see who has access to ownCloud
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: admin gets all users and checks for all the users including the admin user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator gets the list of all users using the provisioning API
-    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 |
-      | admin          |
-
-
-  Scenario: admin gets all users
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator gets the list of all users using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the users returned by the API should include
-      | brand-new-user |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin gets the users in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    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 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:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "brand-new-user" gets the list of all users 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

tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature

@@ -1,61 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: remove subadmin
-  As an admin
-  I want to be able to remove subadmin rights to a user from a group
-  So that I cam manage administrative access rights for groups
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin removes subadmin from a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 removes user "brand-new-user" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not be a subadmin of group "brand-new-group"
-
-
-  Scenario: subadmin tries to remove other subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" removes user "another-subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be a subadmin of group "brand-new-group"
-
-
-  Scenario: normal user tries to remove subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "brand-new-user" removes user "subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "subadmin" should be a subadmin of group "brand-new-group"
-
-
-  Scenario: subadmin should not be able to remove subadmin of another group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group-1" has been created
-    And group "new-group-2" has been created
-    And user "subadmin" has been made a subadmin of group "new-group-1"
-    And user "another-subadmin" has been made a subadmin of group "new-group-2"
-    When user "subadmin" removes user "another-subadmin" from being a subadmin of group "new-group-2" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be a subadmin of group "new-group-2"

tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature

@@ -1,164 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: reset user password
-  As an admin
-  I want to be able to reset a user's password
-  So that I can secure individual access to resources on the ownCloud server
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
-  Scenario: reset user password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @issue-37992 @notToImplementOnOCIS
-  Scenario: admin tries to reset the password of a user that does not exist
-    When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-
-  @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS
-  Scenario: subadmin should be able to reset the password of a user in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    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"
-    When user "subadmin" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to reset the password of a user not in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-
-  Scenario: a user should not be able to reset the password of another user
-    Given these users have been created with small skeleton files:
-      | username         | password   | displayname    | email                    |
-      | brand-new-user   | %regular%  | New user       | brand.new.user@oc.com.np |
-      | another-new-user | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np |
-    When user "another-new-user" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-
-  Scenario: a user should be able to reset their own password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57
-  Scenario Outline: reset user password including emoji
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
-    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 "<password>" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-    Examples:
-      | password      | comment |
-      | 😛 😜         | smileys |
-      | 🐶🐱 🐭       | Animals |
-      | ⌚️ 📱 📲 💻   | objects |
-      | 🚴🏿‍♀️ 🚴‍♂️ | cycling |
-
-  @skipOnOcV10 @issue-37992
-  Scenario: admin tries to reset the password of a user that does not exist on ocis
-    When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "998"
-    And the HTTP status code should be "200"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57
-  Scenario: admin resets password of user with admin permissions
-    Given these users have been created with small skeleton files:
-      | username | password  | displayname | email           |
-      | Alice    | %regular% | New user    | alice@oc.com.np |
-    And user "Alice" has been added to group "admin"
-    When the administrator resets the password of user "Alice" to "%alt1%" using the provisioning API
-    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 "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line
-    But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS
-  Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    And group "new-group" has been created
-    And user "brand-new-user" has been added to group "new-group"
-    And user "brand-new-user" has been made a subadmin of group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to reset the password of another subadmin of same group
-    Given these users have been created with small skeleton files:
-      | username         | password   | displayname | email                      |
-      | another-subadmin | %regular%  | New user    | another.subadmin@oc.com.np |
-      | subadmin         | %subadmin% | Sub Admin   | sub.admin@oc.com.np        |
-    And group "new-group" has been created
-    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" tries to reset the password of user "another-subadmin" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "another-subadmin" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "another-subadmin" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: apps password is preserved when resetting login password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    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 "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     |
-    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 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     |
-    Then the HTTP status code of responses on all endpoints should be "207"
-

tests/acceptance/features/coreApiProvisioning-v2/addUser.feature

@@ -1,224 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: add user
-  As an admin
-  I want to be able to add users
-  So that I can give people controlled individual access to resources on the ownCloud server
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin creates a user
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should exist
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario: admin creates a user with special characters in the username
-    Given the following users have been deleted
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username | password |
-      | a@-+_.b  | %alt1%   |
-      | a space  | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: admin tries to create an existing user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And the API should not return any data
-
-
-  Scenario: admin tries to create an existing disabled user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And user "brand-new-user" has been disabled
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And the API should not return any data
-
-  @notToImplementOnOCIS
-  Scenario: Admin creates a new user and adds him directly to a group
-    Given group "brand-new-group" has been created
-    When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should belong to group "brand-new-group"
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario: admin creates a user and specifies a password with special characters
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username        | password                     | comment                               |
-      | brand-new-user1 | !@#$%^&*()-_+=[]{}:;,.<>?~/\ | special characters                    |
-      | brand-new-user2 | España§àôœ€                  | special European and other characters |
-      | brand-new-user3 | नेपाली                         | Unicode                               |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username        |
-      | brand-new-user1 |
-      | brand-new-user2 |
-      | brand-new-user3 |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username        |
-      | brand-new-user1 |
-      | brand-new-user2 |
-      | brand-new-user3 |
-
-
-  Scenario: admin creates a user and specifies an invalid password, containing just space
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password " " using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "brand-new-user" should not exist
-
-
-  Scenario: admin creates a user and specifies a password containing spaces
-    Given user "brand-new-user" has been deleted
-    When the administrator sends a user creation request for user "brand-new-user" password "spaces in my password" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should exist
-    And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-
-
-  Scenario Outline: admin creates a user with username that contains capital letters
-    When the administrator sends a user creation request for user "<display-name>" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Brand-New-User" should exist
-    And user "BRAND-NEW-USER" should exist
-    And user "brand-new-user" should exist
-    And user "brand-NEW-user" should exist
-    And user "BrAnD-nEw-UsEr" should exist
-    And the display name of user "brand-new-user" should be "<display-name>"
-    Examples:
-      | display-name   |
-      | Brand-New-User |
-      | BRAND-NEW-USER |
-      | brand-new-user |
-      | brand-NEW-user |
-      | BrAnD-nEw-UsEr |
-
-
-  Scenario: admin tries to create an existing user but with username containing capital letters
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator sends a user creation request for user "BRAND-NEW-USER" password "%alt1%" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And the API should not return any data
-
-
-  Scenario: admin creates a user with unusual username
-    Given the following users have been deleted
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username | password |
-      | user-1   | %alt1%   |
-      | null     | %alt1%   |
-      | nil      | %alt1%   |
-      | 123      | %alt1%   |
-      | -123     | %alt1%   |
-      | 0.0      | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should exist
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-    And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt"
-      | username |
-      | user-1   |
-      | null     |
-      | nil      |
-      | 123      |
-      | -123     |
-      | 0.0      |
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to create a user
-    Given user "brand-new-user" has been deleted
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When unauthorized user "subadmin" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "brand-new-user" should not exist
-
-
-  Scenario: normal user should not be able to create another user
-    Given user "brand-new-user" has been deleted
-    And user "Alice" has been created with default attributes and without skeleton files
-    When unauthorized user "Alice" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API
-    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
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When the groupadmin "subadmin" sends a user creation request for user "brand-new-user" password "%alt1%" group "group101" using the provisioning API
-    Then the OCS status code should be "200"
-    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
-    And user "subadmin" has been created with default attributes and without skeleton files
-    And group "group101" has been created
-    And group "group102" has been created
-    And user "subadmin" has been added to group "group101"
-    And user "subadmin" has been made a subadmin of group "group101"
-    When the groupadmin "subadmin" tries to create new user "brand-new-user" password "%alt1%" in other group "group102" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "brand-new-user" should not exist
-
-  @sqliteDB
-  Scenario: admin tries to create user with brackets in the username
-    When the administrator sends a user creation request for the following users with password using the provisioning API
-      | username  | password |
-      | [user1]   | %alt1%   |
-      | [ user2 ] | %alt1%   |
-    Then the OCS status code of responses on all endpoints should be "400"
-    And the HTTP status code of responses on all endpoints should be "400"
-    And the following users should not exist
-      | username  |
-      | [user1]   |
-      | [ user2 ] |

tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature

@@ -1,90 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: access user provisioning API using app password
-  As an ownCloud user
-  I want to be able to use the provisioning API with an app password
-  So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password.
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: admin deletes the user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And a new client token for the administrator has been generated
-    And a new browser session for the administrator has been started
-    And the user has generated a new app password named "my-client"
-    When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "DELETE" using the generated app password
-    Then the HTTP status code should be "200"
-    And user "brand-new-user" should not exist
-
-  @notToImplementOnOCIS
-  Scenario: subadmin gets users in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And user "another-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"
-    And a new client token for "brand-new-user" has been generated
-    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/v2.php/cloud/users" with "GET" using the generated app password
-    Then 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
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | brand-new-user | New User    |
-    And a new client token for "brand-new-user" has been generated
-    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/v2.php/cloud/users/brand-new-user" with "GET" using the generated app password
-    Then the HTTP status code should be "200"
-    And the display name returned by the API should be "New User"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to get users of other group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "another-new-user" has been added to group "another-new-group"
-    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
-    And a new client token for "brand-new-user" has been generated
-    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/v2.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"
-
-
-  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:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And a new client token for "brand-new-user" has been generated
-    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/v2.php/cloud/users/another-new-user" with "GET" using the generated app password
-    Then the HTTP status code should be "401"
-    And the API should not return any data
-
-  @notToImplementOnOCIS
-  Scenario: normal user gets his own resources using the app password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    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 "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 |
-    Then the HTTP status code should be "207"

tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature

@@ -1,60 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: create a subadmin
-  As an admin
-  I want to be able to make a user the subadmin of a group
-  So that I can give administrative privilege of a group to a user
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin creates a subadmin
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    When the administrator makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should be a subadmin of group "brand-new-group"
-
-
-  Scenario: admin tries to create a subadmin using a user which does not exist
-    Given user "nonexistentuser" has been deleted
-    And group "brand-new-group" has been created
-    When the administrator makes user "nonexistentuser" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "nonexistentuser" should not be a subadmin of group "brand-new-group"
-
-
-  Scenario: admin tries to create a subadmin using a group which does not exist
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "not-group" has been deleted
-    When the administrator makes user "brand-new-user" a subadmin of group "not-group" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-
-  @issue-31276 @skipOnOcV10
-  Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "subadmin" makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "brand-new-user" should not be a subadmin of group "brand-new-group"
-
-
-  Scenario: normal user should not be able to make another user a subadmin
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | Alice          |
-      | Brian          |
-    And group "group101" has been created
-    When user "Alice" makes user "Brian" a subadmin of group "group101" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Brian" should not be a subadmin of group "group101"

tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature

@@ -1,21 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to make a user the subadmin of a group
-  So that I can give administrative privilege of a group to a user
-
-  @issue-31276
-  Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given using OCS API version "2"
-    And these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "subadmin" makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "brand-new-user" should not be a subadmin of group "brand-new-group"

tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature

@@ -1,134 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: delete users
-  As an admin
-  I want to be able to delete users
-  So that I can remove user from ownCloud
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: Delete a user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator deletes 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 user "brand-new-user" should not exist
-
-
-  Scenario: Delete a user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    When the administrator deletes the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not exist
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: Delete a user, and specify the user name in different case
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator deletes 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 user "brand-new-user" should not exist
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin deletes a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    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"
-    When user "subadmin" deletes 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 user "brand-new-user" should not exist
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to delete a user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" deletes user "Brian" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should exist
-
-  @notToImplementOnOCIS
-  Scenario: administrator deletes another admin user
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | another-admin  |
-    And user "another-admin" has been added to group "admin"
-    When the administrator deletes user "another-admin" using the provisioning API
-    Then the OCS status code should be "200"
-    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:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    And user "another-subadmin" has been added to group "new-group"
-    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" deletes user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "200"
-    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:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    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" deletes user "another-subadmin" using the provisioning API
-    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:
-      | username       |
-      | subadmin       |
-      | another-admin  |
-    And user "another-admin" has been added to group "admin"
-    And group "new-group" has been created
-    And user "another-admin" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" deletes user "another-admin" using the provisioning API
-    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:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" deletes user "brand-new-user" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "brand-new-user" should exist

tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature

@@ -1,18 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to delete users
-  So that I can remove user from ownCloud
-
-  @issue-31276
-  Scenario: normal user tries to delete a user
-    Given using OCS API version "2"
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" deletes user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should exist

tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature

@@ -1,36 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: disable an app
-  As an admin
-  I want to be able to disable an enabled app
-  So that I can stop the app features being used
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: Admin disables an app
-    Given app "comments" has been enabled
-    When the administrator disables app "comments"
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And app "comments" should be disabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: subadmin tries to disable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been enabled
-    When user "subadmin" disables app "comments"
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to disable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been enabled
-    When user "brand-new-user" disables app "comments"
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled

tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature

@@ -1,30 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to disable an enabled app
-  So that I can stop the app features being used
-
-  Background:
-    Given using OCS API version "2"
-
-  @issue-31276
-  Scenario: subadmin tries to disable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been enabled
-    When user "subadmin" disables app "comments"
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled
-
-  @issue-31276
-  Scenario: normal user tries to disable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been enabled
-    When user "brand-new-user" disables app "comments"
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be enabled

tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature

@@ -1,311 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: disable user
-  As an admin
-  I want to be able to disable a user
-  So that I can remove access to files and resources for a user, without actually deleting the files and resources
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin disables an user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-
-
-  Scenario: admin disables an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    When the administrator disables the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should be disabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: Subadmin should be able to disable an user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-
-  @issue-31276 @skipOnOcV10 @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable an user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And group "another-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "Alice" has been added to group "another-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Alice" should be enabled
-
-  @issue-31276 @skipOnOcV10 @notToImplementOnOCIS
-  Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | subadmin      |
-      | another-admin |
-    And group "brand-new-group" has been created
-    And user "another-admin" has been added to group "admin"
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "another-admin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "another-admin" should be enabled
-
-
-  Scenario: Admin can disable another admin user
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When the administrator disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "another-admin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Admin can disable subadmins in the same group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And the administrator has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When the administrator disables user "subadmin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "subadmin" should be disabled
-
-
-  Scenario: Admin user cannot disable himself
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    When user "another-admin" disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "another-admin" should be enabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: disable an user with a regular user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" disables user "Brian" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable himself
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "subadmin" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And user "subadmin" should be enabled
-
-  @smokeTest
-  Scenario: Making a web request with a disabled user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files"
-    And the HTTP status code should be "403"
-
-
-  Scenario: Disabled user tries to download file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" downloads file "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to upload file
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" uploads file with content "uploaded content" to "newTextFile.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to rename file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" moves file "/textfile0.txt" to "/renamedTextfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to move file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" moves file "/textfile0.txt" to "/PARENT/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to delete file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" deletes file "/textfile0.txt" using the WebDAV API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to share a file
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: Disabled user tries to share a folder
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
-    Then the HTTP status code should be "401"
-
-
-  Scenario: getting shares shared by disabled user (to shares folder)
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" file "/Shares/textfile0.txt" should exist
-    And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line
-
-  @notToImplementOnOCIS
-  Scenario: getting shares shared by disabled user (to root)
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" file "/textfile0.txt" should exist
-    And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line
-
-
-  Scenario: getting shares shared by disabled user in a group (to shares folder)
-    Given the administrator has set the default folder for received shares to "Shares"
-    And auto-accept shares has been disabled
-    And user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And group "group0" has been created
-    And user "Brian" has been added to group "group0"
-    And user "Alice" has shared folder "/PARENT" with group "group0"
-    And user "Brian" has accepted share "/PARENT" offered by user "Alice"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" folder "/Shares/PARENT" should exist
-    And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line
-
-  @notToImplementOnOCIS
-  Scenario: getting shares shared by disabled user in a group (to root)
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Brian" has been created with default attributes and without skeleton files
-    And group "group0" has been created
-    And user "Brian" has been added to group "group0"
-    And user "Alice" has shared folder "/PARENT" with group "group0"
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And as "Brian" folder "/PARENT" should exist
-    And the content of file "/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line
-
-
-  Scenario: Disabled user tries to create public link share
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has been disabled
-    When user "Alice" creates a public link share using the sharing API with settings
-      | path | textfile0.txt |
-    Then the HTTP status code should be "401"
-
-
-  Scenario Outline: getting public link share shared by disabled user using the new public WebDAV API
-    Given user "Alice" has been created with default attributes and small skeleton files
-    And user "Alice" has created a public link share with settings
-      | path        | /textfile0.txt |
-      | permissions | read           |
-    When the administrator disables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be disabled
-    And the public should be able to download the last publicly shared file using the <dav_version> public WebDAV API without a password and the content should be "ownCloud test text file 0" plus end-of-line
-    Examples:
-      | dav_version |
-      | old         |
-      | new         |
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should be able to disable user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "another-subadmin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Subadmin should not be able to disable another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be enabled
-
-
-  Scenario: normal user cannot disable himself
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    When user "Alice" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be enabled

tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature

@@ -1,54 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to disable a user
-  So that I can remove access to files and resources for a user, without actually deleting the files and resources
-
-  Background:
-    Given using OCS API version "2"
-
-  @issue-31276
-  Scenario: Subadmin should not be able to disable an user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And group "another-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "Alice" has been added to group "another-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Alice" should be enabled
-
-  @issue-31276
-  Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | subadmin      |
-      | another-admin |
-    And group "brand-new-group" has been created
-    And user "another-admin" has been added to group "admin"
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "another-admin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" disables user "another-admin" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "another-admin" should be enabled
-
-  @issue-31276
-  Scenario: disable an user with a regular user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    When user "Alice" disables user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should be enabled

tests/acceptance/features/coreApiProvisioning-v2/editUser.feature

@@ -1,355 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: edit users
-  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: the administrator can edit a user email
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  Scenario Outline: the administrator can edit a user email of an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username   | email   |
-      | <username> | <email> |
-    When the administrator changes the email of user "<username>" to "a-different-email@example.com" using the provisioning API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "200"
-    And the email address of user "<username>" should be "a-different-email@example.com"
-    Examples:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-
-  @smokeTest
-  Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display")
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator changes the display 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 the display name of user "brand-new-user" should be "A New User"
-
-
-  Scenario: the administrator can edit a user display name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 the display name of user "brand-new-user" should be "A New User"
-
-
-  Scenario: the administrator can clear a user display name and then it defaults to the username
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And the administrator has changed the display name of user "brand-new-user" to "A New User"
-    When the administrator changes the display name of user "brand-new-user" to "" using the provisioning API
-    Then the HTTP status code should be "200"
-    And the OCS status code should be "200"
-    And the display name of user "brand-new-user" should be "brand-new-user"
-
-  @smokeTest
-  Scenario: the administrator can edit a user quota
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 the quota definition of user "brand-new-user" should be "12 MB"
-
-
-  Scenario: the administrator can override 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 "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 OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  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 "200"
-    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 "200"
-    And the HTTP status code should be "200"
-    And the email address of user "brand-new-user" should be ""
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: a subadmin should be able to edit the user information in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    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"
-    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 OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And 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"
-    And the quota definition of user "brand-new-user" should be "12 MB"
-
-
-  Scenario: a normal user should be able to change their email address
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 |
-    And the email address of user "brand-new-user" should be "brand-new-user@example.com"
-
-
-  Scenario Outline: a normal user should be able to change their display name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When user "brand-new-user" changes the display name of user "brand-new-user" to "<display-name>" 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 | <display-name> |
-    And the display name of user "brand-new-user" should be "<display-name>"
-    Examples:
-      | display-name    |
-      | Alan Border     |
-      | Phil Cyclist 🚴 |
-
-
-  Scenario: a normal user should not be able to change their quota
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 |
-    And the quota definition of user "brand-new-user" should be "default"
-
-  @notToImplementOnOCIS
-  Scenario: the administrator can edit user information with admin permissions
-    Given these users have been created with default attributes and without skeleton files:
-      | username      |
-      | 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 OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And 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"
-    And the quota definition of user "another-admin" should be "12 MB"
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should be able to edit user information with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    And user "another-subadmin" has been added to group "new-group"
-    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 OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And 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"
-    And the quota definition of user "another-subadmin" should be "12 MB"
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should not be able to edit user information of another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group" has been created
-    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 OCS status code of responses on all endpoints should be "997"
-    And the HTTP status code of responses on all endpoints 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
-    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
-    And 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 of responses on all endpoints should be "997"
-    And the HTTP status code of responses on all endpoints should be "401"
-    And the display name of user "Brian" should not have changed
-    And the email address of user "Brian" should not have changed
-
-
-  Scenario: Admin gives access to users to change their email address
-    Given user "Alice" has been created with default attributes and without skeleton files
-    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 "200"
-    And the HTTP status code should be "200"
-    And the attributes of user "Alice" returned by the API should include
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  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
-    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
-      | email | alice@example.org |
-    And the email address of user "Alice" should not have changed
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, admin can still change the 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 the administrator changes the email of user "Alice" to "alice@gmail.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 "Alice" returned by the API should include
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, admin can still change their own email address
-    When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command
-    And the administrator changes the email of user "admin" to "something@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 "admin" returned by the API should include
-      | email | something@example.com |
-    And the email address of user "admin" should be "something@example.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, subadmin can still change the email address of a user they are subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "Alice" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    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 "subadmin" changes the email of user "Alice" to "alice@gmail.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 "Alice" returned by the API should include
-      | email | alice@gmail.com |
-    And the email address of user "Alice" should be "alice@gmail.com"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their email address, subadmin cannot change the email address of a user they are not subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice
-    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 "subadmin" 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
-      | email | alice@example.org |
-    And the email address of user "Alice" should not have changed
-
-
-  Scenario: Admin gives access to users to change their display name
-    Given user "Alice" has been created with default attributes and without skeleton files
-    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 "200"
-    And the HTTP status code should be "200"
-    And the attributes of user "Alice" returned by the API should include
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  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
-    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
-      | displayname | Alice Hansen |
-    And the display name of user "Alice" should not have changed
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, admin can still change 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 the administrator changes the display name of user "Alice" to "Alice Wonderland" 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 "Alice" returned by the API should include
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, admin can still change their own display name
-    When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command
-    And the administrator changes the display name of user "admin" to "The Administrator" 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 "admin" returned by the API should include
-      | displayname | The Administrator |
-    And the display name of user "admin" should be "The Administrator"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, subadmin can still change the display name of a user they are subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "Alice" has been added to group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    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 "subadmin" changes the display name of user "Alice" to "Alice Wonderland" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-      | displayname | Alice Wonderland |
-    And the display name of user "Alice" should be "Alice Wonderland"
-
-  @notToImplementOnOCIS
-  Scenario: Admin does not give access to users to change their display name, subadmin cannot change the display name of a user they are not subadmin of
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | subadmin |
-      | Alice    |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice
-    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 "subadmin" 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
-      | displayname | Alice Hansen |
-    And the display name of user "Alice" should not have changed

tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature

@@ -1,36 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: enable an app
-  As an admin
-  I want to be able to enable a disabled app
-  So that I can use the app features again
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: Admin enables an app
-    Given app "comments" has been disabled
-    When the administrator enables app "comments"
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And app "comments" should be enabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: subadmin tries to enable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been disabled
-    When user "subadmin" enables app "comments"
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to enable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been disabled
-    When user "brand-new-user" enables app "comments"
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled

tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature

@@ -1,30 +0,0 @@
-@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: enable an app - current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to enable a disabled app
-  So that I can use the app features again
-
-  Background:
-    Given using OCS API version "2"
-
-  @issue-31276
-  Scenario: subadmin tries to enable an app
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And app "comments" has been disabled
-    When user "subadmin" enables app "comments"
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled
-
-  @issue-31276
-  Scenario: normal user tries to enable an app
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And app "comments" has been disabled
-    When user "brand-new-user" enables app "comments"
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And app "comments" should be disabled

tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature

@@ -1,172 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: enable user
-  As an admin
-  I want to be able to enable a user
-  So that I can give a user access to their files and resources again if they are now authorized for that
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin enables an user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And user "Alice" has been disabled
-    When the administrator enables user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-
-  Scenario: admin enables an user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username | email               |
-      | a@-+_.b  | a.b@example.com     |
-      | a space  | a.space@example.com |
-    And the following users have been disabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    When the administrator enables the following users using the provisioning API
-      | username |
-      | a@-+_.b  |
-      | a space  |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should be enabled
-      | username |
-      | a@-+_.b  |
-      | a space  |
-
-
-  Scenario: admin enables another admin user
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    And user "another-admin" has been added to group "admin"
-    And user "another-admin" has been disabled
-    When the administrator enables user "another-admin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "another-admin" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: admin enables subadmins in the same group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And the administrator has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been disabled
-    When the administrator enables user "subadmin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "subadmin" should be enabled
-
-
-  Scenario: admin tries to enable himself
-    Given user "another-admin" has been created with default attributes and without skeleton files
-    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 the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    Then user "another-admin" should be disabled
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to enable other user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Brian" has been disabled
-    When user "Alice" tries to enable user "Brian" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to enable himself
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been disabled
-    When user "subadmin" tries to enable user "subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "subadmin" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: Making a web request with an enabled user
-    Given user "Alice" has been created with default attributes and without skeleton files
-    When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files"
-    Then the HTTP status code should be "200"
-
-  @notToImplementOnOCIS
-  Scenario: normal user should not be able to enable himself
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    And user "Alice" has been disabled
-    When user "Alice" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should be able to enable user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to enable user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "Alice" should be disabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should be able to enable user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username    |
-      | Alice       |
-      | subadmin    |
-    And group "brand-new-group" has been created
-    And user "Alice" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been disabled
-    When user "subadmin" tries to enable user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "Alice" should be enabled
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to enable another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username            |
-      | subadmin            |
-      | another-subadmin    |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been disabled
-    When user "subadmin" tries to enable user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be disabled

tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature

@@ -1,19 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: enable user - current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to enable a user
-  So that I can give a user access to their files and resources again if they are now authorized for that
-
-  @issue-31276
-  Scenario: normal user tries to enable other user
-    Given using OCS API version "2"
-    And these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And user "Brian" has been disabled
-    When user "Alice" tries to enable user "Brian" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "Brian" should be disabled

tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature

@@ -1,19 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get app info
-  As an admin
-  I want to be able to get app info
-  So that I can get the information of a specific application
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin gets app info
-    When the administrator gets the info of app "files"
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the XML "data" "id" value should be "files"
-    And the XML "data" "name" value should be "Files"
-    And the XML "data" "types" "element" value should be "filesystem"
-    And the XML "data" "dependencies" "owncloud" "min-version" attribute value should be a valid version string
-    And the XML "data" "dependencies" "owncloud" "max-version" attribute value should be a valid version string

tests/acceptance/features/coreApiProvisioning-v2/getApps.feature

@@ -1,87 +0,0 @@
-@api @provisioning_api-app-required @files_sharing-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get apps
-  As an admin
-  I want to be able to get the list of apps on my ownCloud
-  So that I can manage apps
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest @comments-app-required @files_trashbin-app-required @files_versions-app-required @systemtags-app-required
-  Scenario: admin gets enabled apps
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments             |
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | files_trashbin       |
-      | files_versions       |
-      | provisioning_api     |
-      | systemtags           |
-      | updatenotification   |
-
-
-  Scenario: admin gets enabled apps - check for the minimal list of apps
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-
-  @comments-app-required
-  Scenario: admin gets enabled apps when some app is disabled
-    Given app "comments" has been disabled
-    When the administrator gets all enabled apps using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-    And the apps returned by the API should not include
-      | comments |
-
-  @comments-app-required
-  Scenario: admin gets disabled apps
-    Given app "comments" has been disabled
-    When the administrator gets all disabled apps using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments |
-    And the apps returned by the API should not include
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_sharing        |
-      | updatenotification   |
-
-  @comments-app-required
-  Scenario: admin gets all apps
-    Given app "comments" has been disabled
-    When the administrator gets all apps using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the apps returned by the API should include
-      | comments             |
-      | dav                  |
-      | federatedfilesharing |
-      | federation           |
-      | files                |
-      | files_external       |
-      | files_sharing        |
-      | updatenotification   |

tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature

@@ -1,55 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get subadmins
-  As an admin
-  I want to be able to get the list of subadmins of a group
-  So that I can manage subadmins of a group
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin gets subadmin users of a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 OCS status code should be "200"
-    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
-    And group "nonexistentgroup" has been deleted
-    When the administrator gets all the subadmins of group "nonexistentgroup" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And the API should not return any data
-
-  @issue-31276 @skipOnOcV10
-  Scenario: subadmin tries to get other subadmins of the same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" gets all the subadmins of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to get the subadmins of the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "brand-new-user" gets all the subadmins of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature

@@ -1,37 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get subadmins - current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to get the list of subadmins of a group
-  So that I can manage subadmins of a group
-
-  Background:
-    Given using OCS API version "2"
-
-  @issue-31276
-  Scenario: subadmin tries to get other subadmins of the same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" gets all the subadmins of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data
-
-  @issue-31276
-  Scenario: normal user tries to get the subadmins of the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "brand-new-user" gets all the subadmins of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v2/getUser.feature

@@ -1,211 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get 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 "2"
-
-  @smokeTest
-  Scenario: admin gets an existing user
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | brand-new-user | 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 display name returned by the API should be "Brand 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
-
-
-  Scenario Outline: admin gets an existing user with special characters in the username
-    Given these users have been created without skeleton files:
-      | username   | displayname   | email   |
-      | <username> | <displayname> | <email> |
-    When the administrator retrieves the information of user "<username>" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the display name returned by the API should be "<displayname>"
-    And the email address returned by the API should be "<email>"
-    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:
-      | username | displayname  | email               |
-      | a@-+_.b  | A weird b    | a.b@example.com     |
-      | a space  | A Space Name | a.space@example.com |
-
- 
-  Scenario: admin gets an existing user, providing uppercase username in the URL
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | brand-new-user | 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 display name returned by the API should be "Brand 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
-
-
-  Scenario: admin tries to get a nonexistent user
-    When the administrator retrieves the information of user "not-a-user" using the provisioning API
-    Then the OCS status code should be "404"
-    And the HTTP status code should be "404"
-    And the API should not return any data
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: a subadmin gets information of a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname |
-      | subadmin       | Sub Admin   |
-      | brand-new-user | New User    |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    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 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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin tries to get information of a user not in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "brand-new-user" 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
-
-  @issue-31276 @skipOnOcV10
-  Scenario: a normal user tries to get information of another user
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "another-new-user" retrieves the information of user "brand-new-user" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data
-
-  @smokeTest
-  Scenario: a normal user gets their own information
-    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 "200"
-    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
-
- 
-  Scenario: a normal user gets their own information, providing uppercase username as authentication
-    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 "200"
-    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
-
- 
-  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 "200"
-    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
-
- 
-  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
-    Then the OCS status code should be "200"
-    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
-
- 
-  Scenario: a mixed-case normal user gets their own information, providing the 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
-    Then the OCS status code should be "200"
-    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
-
-  @notToImplementOnOCIS
-  Scenario: admin gets information of a user with admin permissions
-    Given these users have been created with default attributes and without skeleton files:
-      | username       | displayname    |
-      | Alice          | Admin Alice    |
-    And user "Alice" has been added to group "admin"
-    When the administrator retrieves the information of user "Alice" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the display name returned by the API should be "Admin Alice"
-    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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "another-subadmin" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the display name returned by the API should be "Regular 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
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin should not be able to get information of another subadmin of same group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" retrieves the information of user "another-subadmin" 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

tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature

@@ -1,20 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get user - current oC10 behavior for issue-31276
-  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 "2"
-
-  @issue-31276
-  Scenario: a normal user tries to get information of another user
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "another-new-user" retrieves the information of user "brand-new-user" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature

@@ -1,53 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get users
-  As an admin
-  I want to be able to list the users that exist
-  So that I can see who has access to ownCloud
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: admin gets all users where default admin user exists
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator gets the list of all users using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the users returned by the API should be
-      | brand-new-user |
-      | admin          |
-
-
-  Scenario: admin gets all users
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator gets the list of all users using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the users returned by the API should include
-      | brand-new-user |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin gets the users in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    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 OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the users returned by the API should be
-      | brand-new-user |
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to get other users
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "brand-new-user" gets the list of all users using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature

@@ -1,20 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get users - current oC10 behavior for issue-31276
-  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 "2"
-
-  @issue-31276
-  Scenario: normal user tries to get other users
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    When user "brand-new-user" gets the list of all users using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And the API should not return any data

tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature

@@ -1,61 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: remove subadmin
-  As an admin
-  I want to be able to remove subadmin rights to a user from a group
-  So that I cam manage administrative access rights for groups
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin removes subadmin from a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    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 removes user "brand-new-user" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not be a subadmin of group "brand-new-group"
-
-  @issue-31276 @skipOnOcV10
-  Scenario: subadmin tries to remove other subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" removes user "another-subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be a subadmin of group "brand-new-group"
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to remove subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "brand-new-user" removes user "subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "subadmin" should be a subadmin of group "brand-new-group"
-
-
-  Scenario: subadmin should not be able to remove subadmin of another group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "new-group-1" has been created
-    And group "new-group-2" has been created
-    And user "subadmin" has been made a subadmin of group "new-group-1"
-    And user "another-subadmin" has been made a subadmin of group "new-group-2"
-    When user "subadmin" removes user "another-subadmin" from being a subadmin of group "new-group-2" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be a subadmin of group "new-group-2"

tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature

@@ -1,38 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: remove subadmin - current oC10 behavior for issue-31276
-  As an admin
-  I want to be able to remove subadmin rights to a user from a group
-  So that I cam manage administrative access rights for groups
-
-  Background:
-    Given using OCS API version "2"
-
-  @issue-31276
-  Scenario: subadmin tries to remove other subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | subadmin         |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" removes user "another-subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "another-subadmin" should be a subadmin of group "brand-new-group"
-
-  @issue-31276
-  Scenario: normal user tries to remove subadmin in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | subadmin       |
-      | brand-new-user |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "brand-new-user" removes user "subadmin" from being a subadmin of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    #Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And user "subadmin" should be a subadmin of group "brand-new-group"

tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature

@@ -1,157 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: reset user password
-  As an admin
-  I want to be able to reset a user's password
-  So that I can secure individual access to resources on the ownCloud server
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
-  Scenario: reset user password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS @issue-37992
-  Scenario: admin tries to reset the password of a user that does not exist
-    When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-
-  @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS
-  Scenario: subadmin should be able to reset the password of a user in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    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"
-    When user "subadmin" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to reset the password of a user not in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    And group "new-group" has been created
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-
-  Scenario: a user should not be able to reset the password of another user
-    Given these users have been created with small skeleton files:
-      | username         | password   | displayname    | email                    |
-      | brand-new-user   | %regular%  | New user       | brand.new.user@oc.com.np |
-      | another-new-user | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np |
-    When user "another-new-user" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-
-  Scenario: a user should be able to reset their own password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57
-  Scenario Outline: reset user password including emoji
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the content of file "textfile0.txt" for user "brand-new-user" using password "<password>" should be "ownCloud test text file 0" plus end-of-line
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-    Examples:
-      | password      | comment |
-      | 😛 😜         | smileys |
-      | 🐶🐱 🐭       | Animals |
-      | ⌚️ 📱 📲 💻   | objects |
-      | 🚴🏿‍♀️ 🚴‍♂️ | cycling |
-
-  @skipOnOcV10 @issue-37992
-  Scenario: admin tries to reset the password of a user that does not exist on OCIS
-    When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "998"
-    And the HTTP status code should be "404"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS
-  Scenario: admin resets password of user with admin permissions
-    Given these users have been created with small skeleton files:
-      | username | password  | displayname | email           |
-      | Alice    | %regular% | New user    | alice@oc.com.np |
-    And user "Alice" has been added to group "admin"
-    When the administrator resets the password of user "Alice" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    And the HTTP status code should be "200"
-    And the content of file "textfile0.txt" for user "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line
-    But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS
-  Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group
-    Given these users have been created with small skeleton files:
-      | username       | password   | displayname | email                    |
-      | brand-new-user | %regular%  | New user    | brand.new.user@oc.com.np |
-      | subadmin       | %subadmin% | Sub Admin   | sub.admin@oc.com.np      |
-    And group "new-group" has been created
-    And user "brand-new-user" has been added to group "new-group"
-    And user "brand-new-user" has been made a subadmin of group "new-group"
-    And user "subadmin" has been made a subadmin of group "new-group"
-    When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "200"
-    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
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: subadmin should not be able to reset the password of another subadmin of same group
-    Given these users have been created with small skeleton files:
-      | username         | password   | displayname | email                      |
-      | another-subadmin | %regular%  | New user    | another.subadmin@oc.com.np |
-      | subadmin         | %subadmin% | Sub Admin   | sub.admin@oc.com.np        |
-    And group "new-group" has been created
-    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" tries to reset the password of user "another-subadmin" to "%alt1%" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And the content of file "textfile0.txt" for user "another-subadmin" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line
-    But user "another-subadmin" using password "%alt1%" should not be able to download file "textfile0.txt"
-
-  @notToImplementOnOCIS
-  Scenario: apps password is preserved when resetting login password
-    Given these users have been created with small skeleton files:
-      | username       | password  | displayname | email                    |
-      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
-    And a new browser session for "brand-new-user" has been started
-    And the user has generated a new app password named "my-client"
-    And user "brand-new-user" has reset the password of user "brand-new-user" to "%alt1%"
-    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 |
-    Then the HTTP status code should be "207"
-

tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature

@@ -1,187 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: add groups
-  As an admin
-  I want to be able to add groups
-  So that I can more easily manage access to resources by groups rather than individual users
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin creates a group
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname   | comment                               |
-      | simplegroup | nothing special here                  |
-      | España§àôœ€ | special European and other characters |
-      | नेपाली      | Unicode group name                    |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname   |
-      | simplegroup |
-      | España§àôœ€ |
-      | नेपाली      |
-
-  @sqliteDB
-  Scenario: admin creates a group with special characters
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | 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              |
-      | [group1]            | brackets           |
-      | group [ 2 ]         | bracketsAndSpace   |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname           |
-      | brand-new-group     |
-      | the.group           |
-      | left,right          |
-      | 0                   |
-      | Finance (NP)        |
-      | Admin&Finance       |
-      | admin:Pokhara@Nepal |
-      | maint+eng           |
-      | $x<=>[y*z^2]!       |
-      | Mgmt\Middle         |
-      | 😅 😆               |
-      | [group1]            |
-      | group [ 2 ]         |
-
-  @toImplementOnOCIS @issue-product-284
-  Scenario: admin creates a group with % and # in name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname       | comment                                 |
-      | maintenance#123 | Hash sign                               |
-      | 50%pass         | Percent sign (special escaping happens) |
-      | 50%25=0         | %25 literal looks like an escaped "%"   |
-      | 50%2Fix         | %2F literal looks like an escaped slash |
-      | 50%2Eagle       | %2E literal looks like an escaped "."   |
-      | staff?group     | Question mark                           |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname       |
-      | maintenance#123 |
-      | 50%pass         |
-      | 50%25=0         |
-      | 50%2Fix         |
-      | 50%2Eagle       |
-      | staff?group     |
-
-  @toImplementOnOCIS
-  Scenario: group names are case-sensitive, multiple groups can exist with different upper and lower case names
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname             |
-      | Case-Sensitive-Group1 |
-      | case-sensitive-group1 |
-      | Case-Sensitive-Group2 |
-      | CASE-SENSITIVE-GROUP2 |
-      | case-sensitive-group3 |
-      | CASE-SENSITIVE-GROUP3 |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname             |
-      | Case-Sensitive-Group1 |
-      | case-sensitive-group1 |
-      | Case-Sensitive-Group2 |
-      | CASE-SENSITIVE-GROUP2 |
-      | case-sensitive-group3 |
-      | CASE-SENSITIVE-GROUP3 |
-    And these groups should not exist:
-      | groupname             |
-      | CASE-SENSITIVE-GROUP1 |
-      | case-sensitive-group2 |
-      | Case-Sensitive-Group3 |
-
-  @issue-31015 @skipOnOcV10 @toImplementOnOCIS @issue-product-284
-  Scenario: admin creates a group with a forward-slash in the group name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-
-  # A group name must not end in "/subadmins" because that would create ambiguity
-  # with the endpoint for getting the subadmins of a group
-  @issue-31015 @skipOnOcV10 @notToImplementOnOCIS
-  Scenario: admin tries to create a group with name ending in "/subadmins"
-    Given group "brand-new-group" has been created
-    When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And group "priv/subadmins" should not exist
-
-
-  Scenario: admin tries to create a group that already exists
-    Given group "brand-new-group" has been created
-    When the administrator sends a group creation request for group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And group "brand-new-group" should exist
-
-
-  Scenario: normal user tries to create a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When user "brand-new-user" tries to send a group creation request for group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And group "brand-new-group" should not exist
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to create a group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" tries to send a group creation request for group "another-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And group "another-new-group" should not exist
-
-
-  Scenario: admin tries to create a group that has white space at the end of the name
-    When the administrator sends a group creation request for group "white-space-at-end " using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And group "white-space-at-end " should not exist
-    And group "white-space-at-end" should not exist
-
-
-  Scenario: admin tries to create a group that has white space at the start of the name
-    When the administrator sends a group creation request for group " white-space-at-start" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And group " white-space-at-start" should not exist
-    But group "white-space-at-start" should not exist
-
-
-  Scenario: admin tries to create a group that is a single space
-    When the administrator sends a group creation request for group " " using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And group " " should not exist
-
-
-  Scenario: admin tries to create a group that is the empty string
-    When the administrator tries to send a group creation request for group "" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"

tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature

@@ -1,58 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: add groups
-  As an admin
-  I want to be able to add groups
-  So that I can more easily manage access to resources by groups rather than individual users
-
-  Background:
-    Given using OCS API version "1"
-
-    # Note: these groups do get created OK, but:
-    # 1) the "should exist" step fails because the API to check their existence does not work.
-    # 2) the ordinary group deletion in AfterScenario does not work, because the
-    #    group-delete API does not work for groups with a slash in the name
-  @issue-31015
-  Scenario: admin creates a group with a forward-slash in the group name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following groups should not exist
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-    #    And the following groups should exist
-    #      | groupname        |
-    #      | Mgmt/Sydney      |
-    #      | Mgmt//NSW/Sydney |
-    #      | var/../etc       |
-    #      | priv/subadmins/1 |
-    #
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, this should not be needed.
-    And the administrator deletes the following groups using the occ command
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-
-  # A group name must not end in "/subadmins" because that would create ambiguity
-  # with the endpoint for getting the subadmins of a group
-  @issue-31015
-  Scenario: admin tries to create a group with name ending in "/subadmins"
-    Given group "brand-new-group" has been created
-    When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API
-    Then the OCS status code should be "100"
-    #Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And group "priv/subadmins" should not exist
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, this should not be needed.
-    And the administrator deletes group "priv/subadmins" using the occ command

tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature

@@ -1,228 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-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 using OCS API version "1"
-
-  @smokeTest @skipOnLDAP
-  Scenario: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And these groups have been created:
-      | groupname   |
-      | simplegroup |
-      | España§àôœ€ |
-      | नेपाली        |
-    When the administrator adds the following users to the following groups using the provisioning API
-      | username       | groupname   | comment                               |
-      | brand-new-user | simplegroup | nothing special here                  |
-      | brand-new-user | España§àôœ€ | special European and other characters |
-      | brand-new-user | नेपाली        | Unicode group name                    |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-
-  @skipOnLDAP
-  Scenario: adding a user to a group with special character in its name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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 provisioning API
-      | username       | groupname           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | the.group           |
-      | brand-new-user | left,right          |
-      | brand-new-user | 0                   |
-      | brand-new-user | Finance (NP)        |
-      | brand-new-user | Admin&Finance       |
-      | brand-new-user | maint+eng           |
-      | brand-new-user | $x<=>[y*z^2]!       |
-      | brand-new-user | 😁 😂               |
-      | brand-new-user | admin:Pokhara@Nepal |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-
-  # once the issue is fixed merge with scenario above
-  @skipOnLDAP @toImplementOnOCIS @issue-product-284
-  Scenario: adding a user to a group with % and # in its name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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 provisioning API
-      | username       | groupname           |
-      | brand-new-user | maintenance#123     |
-      | brand-new-user | 50%pass             |
-      | brand-new-user | 50%25=0             |
-      | brand-new-user | 50%2Eagle           |
-      | brand-new-user | 50%2Fix             |
-      | brand-new-user | Mgmt\Middle         |
-      | brand-new-user | staff?group         |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-
-  @issue-31015 @skipOnLDAP
-  Scenario: adding a user to a group that has a forward-slash in the group name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    # After fixing issue-31015, change the following step to "has been created"
-    And the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    #And group "<group_id>" has been created
-    When the administrator adds the following users to the following groups using the provisioning API
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | priv/subadmins/1 |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, remove the following step:
-    And the administrator deletes the following groups using the occ command
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | priv/subadmins/1 |
-
-  @skipOnLDAP  @toImplementOnOCIS
-  Scenario: adding a user to a group using mixes of upper and lower case in user and group names
-    Given user "mixed-case-user" has been created with default attributes and without skeleton files
-    And these groups have been created:
-      | groupname             |
-      | Case-Sensitive-Group1 |
-      | case-sensitive-group1 |
-      | CASE-SENSITIVE-GROUP1 |
-      | Case-Sensitive-Group2 |
-      | case-sensitive-group2 |
-      | CASE-SENSITIVE-GROUP2 |
-      | Case-Sensitive-Group3 |
-      | case-sensitive-group3 |
-      | CASE-SENSITIVE-GROUP3 |
-    When the administrator adds the following users to the following groups using the provisioning API
-      | username        | groupname             |
-      | Mixed-Case-USER | Case-Sensitive-Group1 |
-      | mixed-case-user | case-sensitive-group2 |
-      | MIXED-CASE-USER | CASE-SENSITIVE-GROUP3 |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should belong to the following groups
-      | username        | groupname             |
-      | Mixed-Case-USER | Case-Sensitive-Group1 |
-      | Mixed-Case-User | case-sensitive-group2 |
-      | mixed-case-user | CASE-SENSITIVE-GROUP3 |
-    But the following users should not belong to the following groups
-      | username        | groupname             |
-      | Mixed-Case-USER | Case-Sensitive-Group2 |
-      | mixed-case-user | case-sensitive-group1 |
-      | MIXED-CASE-USER | CASE-SENSITIVE-GROUP1 |
-      | Mixed-Case-USER | Case-Sensitive-Group3 |
-      | mixed-case-user | case-sensitive-group3 |
-      | MIXED-CASE-USER | CASE-SENSITIVE-GROUP2 |
-
-  @skipOnLDAP
-  Scenario: normal user tries to add himself to a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When user "brand-new-user" tries to add himself to group "brand-new-group" 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
-
-  @skipOnLDAP
-  Scenario: admin tries to add user to a group which does not exist
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "nonexistentgroup" has been deleted
-    When the administrator tries to add user "brand-new-user" to group "nonexistentgroup" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-  @skipOnLDAP
-  Scenario: admin tries to add user to a group without sending the group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When the administrator tries to add user "brand-new-user" to group "" using the provisioning API
-    Then the OCS status code should be "101"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-  @skipOnLDAP
-  Scenario: admin tries to add a user which does not exist to a group
-    Given user "nonexistentuser" has been deleted
-    And group "brand-new-group" has been created
-    When the administrator tries to add user "nonexistentuser" to group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "103"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-  @skipOnLDAP @notToImplementOnOCIS
-  Scenario: a subadmin cannot add users to groups the subadmin is responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | brand-new-user |
-      | subadmin       |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "104"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not belong to group "brand-new-group"
-
-  @skipOnLDAP @notToImplementOnOCIS
-  Scenario: a subadmin cannot add users to groups the subadmin is not responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "another-subadmin" has been made a subadmin of group "another-new-group"
-    When user "another-subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "104"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not belong to group "brand-new-group"
-
-  @skipOnLDAP @notToImplementOnOCIS
-  Scenario: a subadmin can add users to other groups the subadmin is responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "another-new-group"
-    When user "another-subadmin" tries to add user "brand-new-user" to group "another-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should belong to group "brand-new-group"
-
-  # merge this with scenario on line 62 once the issue is fixed
-  @issue-31015 @skipOnLDAP @toImplementOnOCIS @issue-product-284
-  Scenario Outline: adding a user to a group that has a forward-slash and dot in the group name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And the administrator sends a group creation request for group "<group_id>" using the provisioning API
-    When the administrator adds user "brand-new-user" to group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    Examples:
-      | group_id         | comment                            |
-      | var/../etc       | using slash-dot-dot                |

tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature

@@ -1,119 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: delete groups
-  As an admin
-  I want to be able to delete groups
-  So that I can remove unnecessary groups
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario Outline: admin deletes a group
-    Given group "<group_id>" has been created
-    When the administrator deletes group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id>" should not exist
-    Examples:
-      | group_id    | comment                               |
-      | simplegroup | nothing special here                  |
-      | España§àôœ€ | special European and other characters |
-      | नेपाली      | Unicode group name                    |
-
-
-  Scenario Outline: admin deletes a group
-    Given group "<group_id>" has been created
-    When the administrator deletes group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id>" should not exist
-    Examples:
-      | group_id            | 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                                   |
-
-  @toImplementOnOCIS
-  Scenario Outline: admin deletes a group
-    Given group "<group_id>" has been created
-    When the administrator deletes group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id>" should not exist
-    Examples:
-      | group_id            | 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 |
-      | staff?group         | Question mark                           |
-
-  @toImplementOnOCIS
-  Scenario Outline: group names are case-sensitive, the correct group is deleted
-    Given group "<group_id1>" has been created
-    And group "<group_id2>" has been created
-    And group "<group_id3>" has been created
-    When the administrator deletes group "<group_id1>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id1>" should not exist
-    But group "<group_id2>" should exist
-    And group "<group_id3>" should exist
-    Examples:
-      | group_id1            | group_id2            | group_id3            |
-      | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
-      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
-      | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
-
-  @issue-31015 @skipOnOcV10
-  Scenario Outline: admin deletes a group that has a forward-slash in the group name
-    Given group "<group_id>" has been created
-    When the administrator deletes group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id>" should not exist
-    Examples:
-      | group_id         | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-
-
-  Scenario: normal user tries to delete the group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "brand-new-user" tries to delete group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And group "brand-new-group" should exist
-
-  @notToImplementOnOCIS
-  Scenario: subadmin of the group tries to delete the group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" tries to delete group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And group "brand-new-group" should exist
-
-  @issue-31015 @skipOnOcV10 @toImplementOnOCIS
-  Scenario Outline: admin deletes a group that has a forward-slash in the group name
-    Given group "<group_id>" has been created
-    When the administrator deletes group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And group "<group_id>" should not exist
-    Examples:
-      | group_id   | comment             |
-      | var/../etc | using slash-dot-dot |

tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature

@@ -1,42 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: delete groups
-  As an admin
-  I want to be able to delete groups
-  So that I can remove unnecessary groups
-
-  Background:
-    Given using OCS API version "1"
-
-  @issue-31015
-  Scenario: admin deletes a group that has a forward-slash in the group name
-    # After fixing issue-31015, change the following step to "has been created"
-    Given the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    When the administrator deletes the following groups using the provisioning API
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-    # After fixing issue-31015, change the expected status to "100"
-    #Then the OCS status code should be "100"
-    Then the HTTP status code of responses on all endpoints should be "404"
-    #And the HTTP status code should be "200"
-    And the following groups should not exist
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, remove the following step:
-    And the administrator deletes the following groups using the occ command
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |

tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature

@@ -1,90 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get group
-  As an admin
-  I want to be able to get group details
-  So that I can know which users are in a group
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin gets users in the group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | brand-new-user |
-      | 123            |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "123" has been added to group "brand-new-group"
-    When the administrator gets all the members of group "brand-new-group" using the provisioning API
-    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 |
-      | 123            |
-
-
-  Scenario: admin tries to get users in the empty group
-    Given group "brand-new-group" has been created
-    When the administrator gets all the members of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the list of users returned by the API should be empty
-
-
-  Scenario: admin tries to get users in a nonexistent group
-    Given group "brand-new-group" has been created
-    When the administrator gets all the members of group "nonexistentgroup" using the provisioning API
-    Then the OCS status code should be "998"
-    And the HTTP status code should be "200"
-
-  @toImplementOnOCIS
-  Scenario Outline: admin tries to get users in a group but using wrong case of the group name
-    Given group "<group_id1>" has been created
-    When the administrator gets all the members of group "<group_id2>" using the provisioning API
-    Then the OCS status code should be "998"
-    And the HTTP status code should be "200"
-    Examples:
-      | group_id1            | group_id2            |
-      | case-sensitive-group | Case-Sensitive-Group |
-      | case-sensitive-group | CASE-SENSITIVE-GROUP |
-      | Case-Sensitive-Group | case-sensitive-group |
-      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
-      | CASE-SENSITIVE-GROUP | Case-Sensitive-Group |
-      | CASE-SENSITIVE-GROUP | case-sensitive-group |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin gets users in a group they are responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-      | subadmin |
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been added to group "brand-new-group"
-    And user "Brian" has been added to group "brand-new-group"
-    When user "subadmin" gets all the members of group "brand-new-group" using the provisioning API
-    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
-      | Alice |
-      | Brian |
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to get users in a group they are not responsible for
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And group "another-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" gets all the members of group "another-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-
-
-  Scenario: normal user tries to get users in their group
-    Given user "newuser" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    When user "newuser" gets all the members of group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"

tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature

@@ -1,56 +0,0 @@
-@api @provisioning_api-app-required @rememberGroupsThatExist @skipOnLDAP @skipOnGraph
-Feature: get groups
-  As an admin
-  I want to be able to get groups
-  So that I can see all the groups in my ownCloud
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @skipOnLdap @issue-ldap-500
-  Scenario: admin gets all the groups where admin group exists
-    Given group "0" has been created
-    And group "brand-new-group" has been created
-    And group "España" has been created
-    When the administrator gets all the groups using the provisioning API
-    Then the extra groups returned by the API should be
-      | España          |
-      | brand-new-group |
-      | 0               |
-
-  @skipOnLdap @issue-ldap-499
-  Scenario: admin gets all the groups, including groups with mixed case
-    Given group "case-sensitive-group" has been created
-    And group "Case-Sensitive-Group" has been created
-    And group "CASE-SENSITIVE-GROUP" has been created
-    When the administrator gets all the groups using the provisioning API
-    Then the extra groups returned by the API should be
-      | case-sensitive-group |
-      | Case-Sensitive-Group |
-      | CASE-SENSITIVE-GROUP |
-
-  @notToImplementOnOCIS
-  Scenario: subadmin gets all the groups
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And group "0" has been created
-    And group "España" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" gets all the groups using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the extra groups returned by the API should be
-      | España          |
-      | brand-new-group |
-      | 0               |
-
-
-  Scenario: normal user cannot get a list of all the groups
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And group "0" has been created
-    And group "España" has been created
-    When user "Alice" gets all the groups 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

tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature

@@ -1,75 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get subadmin groups
-  As an admin
-  I want to be able to get the groups in which the user is subadmin
-  So that I can know in which groups the user has administrative rights
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin gets subadmin groups of a user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And group "😅 😆" has been created
-    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been made a subadmin of group "😅 😆"
-    When the administrator gets all the groups where user "brand-new-user" is subadmin using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the subadmin groups returned by the API should be
-      | brand-new-group |
-      | 😅 😆           |
-
-
-  Scenario: admin tries to get subadmin groups of a user which does not exist
-    Given user "nonexistentuser" has been deleted
-    And group "brand-new-group" has been created
-    When the administrator gets all the groups where user "nonexistentuser" is subadmin 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
-
-  @issue-owncloud-sdk-658
-  Scenario: subadmin gets groups where he/she is subadmin
-    Given user "Alice" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And group "😅 😆" has been created
-    And user "Alice" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been made a subadmin of group "😅 😆"
-    When user "Alice" gets all the groups where user "Alice" is subadmin using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the subadmin groups returned by the API should be
-      | brand-new-group |
-      | 😅 😆           |
-
-
-  Scenario: subadmin of a group should not be able to get subadmin groups of another subadmin user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And group "brand-new-group" has been created
-    And group "😅 😆" has been created
-    And user "Alice" has been made a subadmin of group "brand-new-group"
-    And user "Brian" has been made a subadmin of group "😅 😆"
-    When user "Alice" tries to get all the groups where user "Brian" is subadmin 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 should not be able to get subadmin groups of a subadmin user
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-      | Brian    |
-    And group "brand-new-group" has been created
-    And group "😅 😆" has been created
-    And user "Alice" has been made a subadmin of group "brand-new-group"
-    And user "Alice" has been made a subadmin of group "😅 😆"
-    When user "Brian" tries to get all the groups where user "Alice" is subadmin 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

tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature

@@ -1,163 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: get user groups
-  As an admin
-  I want to be able to get groups
-  So that I can manage group membership
-
-  Background:
-    Given using OCS API version "1"
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: admin gets groups of an user
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    And group "brand-new-group" has been created
-    And group "0" has been created
-    And group "Admin & Finance (NP)" has been created
-    And group "admin:Pokhara@Nepal" has been created
-    And group "नेपाली" has been created
-    And group "😅 😆" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "brand-new-user" has been added to group "0"
-    And user "brand-new-user" has been added to group "Admin & Finance (NP)"
-    And user "brand-new-user" has been added to group "admin:Pokhara@Nepal"
-    And user "brand-new-user" has been added to group "नेपाली"
-    And user "brand-new-user" has been added to group "😅 😆"
-    When the administrator gets all the groups 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 groups returned by the API should be
-      | brand-new-group      |
-      | 0                    |
-      | Admin & Finance (NP) |
-      | admin:Pokhara@Nepal  |
-      | नेपाली               |
-      | 😅 😆                |
-
-  @issue-31015 @skipOnOcV10
-  Scenario: admin gets groups of an user, including groups containing a slash
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    And group "Mgmt/Sydney" has been created
-    And group "var/../etc" has been created
-    And group "priv/subadmins/1" has been created
-    And user "brand-new-user" has been added to group "Mgmt/Sydney"
-    And user "brand-new-user" has been added to group "var/../etc"
-    And user "brand-new-user" has been added to group "priv/subadmins/1"
-    When the administrator gets all the groups 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 groups returned by the API should be
-      | Mgmt/Sydney      |
-      | var/../etc       |
-      | priv/subadmins/1 |
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: subadmin tries to get other groups of a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | brand-new-user |
-      | subadmin       |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "brand-new-user" has been added to group "another-new-group"
-    When user "subadmin" gets all the groups 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 groups returned by the API should include "brand-new-group"
-    And the groups returned by the API should not include "another-new-group"
-
-
-  Scenario: normal user tries to get the groups of another user
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    When user "another-new-user" gets all the groups of user "brand-new-user" 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
-
-  @notToImplementOnOCIS
-  Scenario: admin gets groups of an user who is not in any groups
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    When the administrator gets all the groups 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 list of groups returned by the API should be empty
-
-  @smokeTest @skipOnOcV10
-  Scenario: admin gets groups of an user on ocis
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    And group "brand-new-group" has been created
-    And group "0" has been created
-    And group "Admin & Finance (NP)" has been created
-    And group "admin:Pokhara@Nepal" has been created
-    And group "नेपाली" has been created
-    And group "😅 😆" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "brand-new-user" has been added to group "0"
-    And user "brand-new-user" has been added to group "Admin & Finance (NP)"
-    And user "brand-new-user" has been added to group "admin:Pokhara@Nepal"
-    And user "brand-new-user" has been added to group "नेपाली"
-    And user "brand-new-user" has been added to group "😅 😆"
-    When the administrator gets all the groups 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 groups returned by the API should be
-      | brand-new-group      |
-      | 0                    |
-      | Admin & Finance (NP) |
-      | admin:Pokhara@Nepal  |
-      | नेपाली               |
-      | 😅 😆                |
-      | users                |
-
-  @skipOnOcV10
-  Scenario: admin gets groups of an user who is not in any groups on ocis
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    When the administrator gets all the groups 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 groups returned by the API should be
-      | users |
-
-  @notToImplementOnOCIS
-  Scenario: normal user gets his/her groups
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    And group "group1" has been created
-    And group "group2" has been created
-    And user "Alice" has been added to group "group1"
-    And user "Alice" has been added to group "group2"
-    When user "Alice" gets all the groups of user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the groups returned by the API should be
-      | group1 |
-      | group2 |
-
-  @skipOnOcV10
-  Scenario: normal user gets his/her groups in ocis
-    Given these users have been created with default attributes and without skeleton files:
-      | username |
-      | Alice    |
-    And group "group1" has been created
-    And group "group2" has been created
-    And user "Alice" has been added to group "group1"
-    And user "Alice" has been added to group "group2"
-    When user "Alice" gets all the groups of user "Alice" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And the groups returned by the API should be
-      | group1 |
-      | group2 |
-      | users  |

tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature

@@ -1,35 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: get user groups
-  As an admin
-  I want to be able to get groups
-  So that I can manage group membership
-
-  Background:
-    Given using OCS API version "1"
-
-  @issue-31015
-  Scenario: admin gets groups of an user, including groups containing a slash
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "unused-group" has been created
-    # After fixing issue-31015, change the following steps to "has been created"
-    And the administrator sends a group creation request for group "Mgmt/Sydney" using the provisioning API
-    And the administrator sends a group creation request for group "var/../etc" using the provisioning API
-    And the administrator sends a group creation request for group "priv/subadmins/1" using the provisioning API
-    #And group "Mgmt/Sydney" has been created
-    #And group "var/../etc" has been created
-    #And group "priv/subadmins/1" has been created
-    And user "brand-new-user" has been added to group "Mgmt/Sydney"
-    And user "brand-new-user" has been added to group "var/../etc"
-    And user "brand-new-user" has been added to group "priv/subadmins/1"
-    When the administrator gets all the groups 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 groups returned by the API should be
-      | Mgmt/Sydney      |
-      | var/../etc       |
-      | priv/subadmins/1 |
-    # The following steps are needed so that the groups do get cleaned up.
-    # After fixing issue-31015, remove the following steps:
-    And the administrator deletes group "Mgmt/Sydney" using the occ command
-    And the administrator deletes group "var/../etc" using the occ command
-    And the administrator deletes group "priv/subadmins/1" using the occ command

tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature

@@ -1,243 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-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 using OCS API version "1"
-
-  @smokeTest
-  Scenario: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | España§àôœ€         |
-      | brand-new-user | नेपाली                |
-    When the administrator removes the following users from the following groups using the provisioning API
-      | username       | groupname           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | España§àôœ€         |
-      | brand-new-user | नेपाली                |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not belong to the following groups
-      | username       | groupname           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | España§àôœ€         |
-      | brand-new-user | नेपाली                |
-
-
-  Scenario: admin removes a user from a group with special characters
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | the.group           |
-      | brand-new-user | left,right          |
-      | brand-new-user | 0                   |
-      | brand-new-user | Finance (NP)        |
-      | brand-new-user | Admin&Finance       |
-      | brand-new-user | admin:Pokhara@Nepal |
-      | brand-new-user | maint+eng           |
-      | brand-new-user | $x<=>[y*z^2]!       |
-      | brand-new-user | Mgmt\Middle         |
-      | brand-new-user | 😁 😂               |
-    When the administrator removes the following users from the following groups using the provisioning API
-      | username       | groupname           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | the.group           |
-      | brand-new-user | left,right          |
-      | brand-new-user | 0                   |
-      | brand-new-user | Finance (NP)        |
-      | brand-new-user | Admin&Finance       |
-      | brand-new-user | admin:Pokhara@Nepal |
-      | brand-new-user | maint+eng           |
-      | brand-new-user | $x<=>[y*z^2]!       |
-      | brand-new-user | Mgmt\Middle         |
-      | brand-new-user | 😁 😂               |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not belong to the following groups
-      | username       | groupname           |
-      | brand-new-user | brand-new-group     |
-      | brand-new-user | the.group           |
-      | brand-new-user | left,right          |
-      | brand-new-user | 0                   |
-      | brand-new-user | Finance (NP)        |
-      | brand-new-user | Admin&Finance       |
-      | brand-new-user | admin:Pokhara@Nepal |
-      | brand-new-user | maint+eng           |
-      | brand-new-user | $x<=>[y*z^2]!       |
-      | brand-new-user | Mgmt\Middle         |
-      | brand-new-user | 😁 😂               |
-
-  @toImplementOnOCIS
-  Scenario: admin removes a user from a group with % and # in their names
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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 |
-      | staff?group         | Question mark                           |
-    And the following users have been added to the following groups
-      | username       | groupname           |
-      | brand-new-user | maintenance#123     |
-      | brand-new-user | 50%pass             |
-      | brand-new-user | 50%25=0             |
-      | brand-new-user | 50%2Eagle           |
-      | brand-new-user | 50%2Fix             |
-      | brand-new-user | staff?group         |
-    When the administrator removes the following users from the following groups using the provisioning API
-      | username       | groupname           |
-      | brand-new-user | maintenance#123     |
-      | brand-new-user | 50%pass             |
-      | brand-new-user | 50%25=0             |
-      | brand-new-user | 50%2Eagle           |
-      | brand-new-user | 50%2Fix             |
-      | brand-new-user | staff?group         |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not belong to the following groups
-      | username       | groupname           |
-      | brand-new-user | maintenance#123     |
-      | brand-new-user | 50%pass             |
-      | brand-new-user | 50%25=0             |
-      | brand-new-user | 50%2Eagle           |
-      | brand-new-user | 50%2Fix             |
-      | brand-new-user | staff?group         |
-
-  @issue-31015 @skipOnOcV10
-  Scenario: admin removes a user from a group that has a forward-slash in the group name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And 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 |
-    And the following users have been added to the following groups
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | priv/subadmins/1 |
-    When the administrator removes the following users from the following groups using the provisioning API
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | priv/subadmins/1 |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not belong to the following groups
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | priv/subadmins/1 |
-
-  @toImplementOnOCIS
-  Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "<group_id1>" has been created
-    And group "<group_id2>" has been created
-    And group "<group_id3>" has been created
-    And user "brand-new-user" has been added to group "<group_id1>"
-    And user "brand-new-user" has been added to group "<group_id2>"
-    And user "brand-new-user" has been added to group "<group_id3>"
-    When the administrator removes user "<user_id>" from group "<group_id1>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not belong to group "<group_id1>"
-    But user "brand-new-user" should belong to group "<group_id2>"
-    And user "brand-new-user" should belong to group "<group_id3>"
-    Examples:
-      | user_id        | group_id1   | group_id2   | group_id3   |
-      | BRAND-NEW-USER | Mixed-Group | mixed-group | MIXED-GROUP |
-      | Brand-New-User | mixed-group | MIXED-GROUP | Mixed-Group |
-      | brand-new-user | MIXED-GROUP | Mixed-Group | mixed-group |
-
-
-  Scenario: admin tries to remove a user from a group which does not exist
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "nonexistentgroup" has been deleted
-    When the administrator removes user "brand-new-user" from group "nonexistentgroup" using the provisioning API
-    Then the OCS status code should be "102"
-    And the HTTP status code should be "200"
-    And the API should not return any data
-
-  @smokeTest @notToImplementOnOCIS
-  Scenario: a subadmin can remove users from groups the subadmin is responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username       |
-      | brand-new-user |
-      | subadmin       |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not belong to group "brand-new-group"
-
-  @notToImplementOnOCIS
-  Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-subadmin |
-    And group "brand-new-group" has been created
-    And group "another-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "another-subadmin" has been made a subadmin of group "another-new-group"
-    When user "another-subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "104"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should belong to group "brand-new-group"
-
-
-  Scenario: normal user tries to remove a user in their group
-    Given these users have been created with default attributes and without skeleton files:
-      | username         |
-      | brand-new-user   |
-      | another-new-user |
-    And group "brand-new-group" has been created
-    And user "brand-new-user" has been added to group "brand-new-group"
-    And user "another-new-user" has been added to group "brand-new-group"
-    When user "brand-new-user" tries to remove user "another-new-user" from group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And user "another-new-user" should belong to group "brand-new-group"
-
-  # merge this with scenario on line 62 once the issue is fixed
-  @issue-31015 @skipOnOcV10 @toImplementOnOCIS
-  Scenario Outline: admin removes a user from a group that has a forward-slash and dot in the group name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    And group "<group_id>" has been created
-    And user "brand-new-user" has been added to group "<group_id>"
-    When the administrator removes user "brand-new-user" from group "<group_id>" using the provisioning API
-    Then the OCS status code should be "100"
-    And the HTTP status code should be "200"
-    And user "brand-new-user" should not belong to group "<group_id>"
-    Examples:
-      | group_id         | comment                            |
-      | var/../etc       | using slash-dot-dot                |

tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature

@@ -1,48 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-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 using OCS API version "1"
-
-  @issue-31015
-  Scenario: admin removes a user from a group that has a forward-slash in the group name
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    # After fixing issue-31015, change the following step to "has been created"
-    And the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    #And group "<group_id>" has been created
-    And the following users have been added to the following groups
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | var/../etc       |
-      | brand-new-user | priv/subadmins/1 |
-    When the administrator removes the following users from the following groups using the provisioning API
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | var/../etc       |
-      | brand-new-user | priv/subadmins/1 |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And the following users should not belong to the following groups
-      | username       | groupname        |
-      | brand-new-user | Mgmt/Sydney      |
-      | brand-new-user | Mgmt//NSW/Sydney |
-      | brand-new-user | var/../etc       |
-      | brand-new-user | priv/subadmins/1 |
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, remove the following step:
-    And the administrator deletes the following groups using the occ command
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |

tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature

@@ -1,183 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph
-Feature: add groups
-  As an admin
-  I want to be able to add groups
-  So that I can more easily manage access to resources by groups rather than individual users
-
-  Background:
-    Given using OCS API version "2"
-
-  @smokeTest
-  Scenario: admin creates a group
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname   | comment                               |
-      | simplegroup | nothing special here                  |
-      | España§àôœ€ | special European and other characters |
-      | नेपाली        | Unicode group name                    |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname   |
-      | simplegroup |
-      | España§àôœ€ |
-      | नेपाली        |
-
-
-  Scenario: admin creates a group with special characters
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | 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                                   |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname           |
-      | brand-new-group     |
-      | the.group           |
-      | left,right          |
-      | 0                   |
-      | Finance (NP)        |
-      | Admin&Finance       |
-      | admin:Pokhara@Nepal |
-      | maint+eng           |
-      | $x<=>[y*z^2]!       |
-      | Mgmt\Middle         |
-      | 😅 😆               |
-
-  @toImplementOnOCIS @issue-product-284
-  Scenario: admin creates a group with % in name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname           | comment                                 |
-      | maintenance#123     | Hash sign                               |
-      | 50%pass             | Percent sign (special escaping happens) |
-      | 50%25=0             | %25 literal looks like an escaped "%"   |
-      | 50%2Fix             | %2F literal looks like an escaped slash |
-      | 50%2Eagle           | %2E literal looks like an escaped "."   |
-      | staff?group         | Question mark                           |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname           |
-      | maintenance#123     |
-      | 50%pass             |
-      | 50%25=0             |
-      | 50%2Fix             |
-      | 50%2Eagle           |
-      | staff?group         |
-
-  @toImplementOnOCIS
-  Scenario: group names are case-sensitive, multiple groups can exist with different upper and lower case names
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname             |
-      | Case-Sensitive-Group1 |
-      | case-sensitive-group1 |
-      | Case-Sensitive-Group2 |
-      | CASE-SENSITIVE-GROUP2 |
-      | case-sensitive-group3 |
-      | CASE-SENSITIVE-GROUP3 |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname             |
-      | Case-Sensitive-Group1 |
-      | case-sensitive-group1 |
-      | Case-Sensitive-Group2 |
-      | CASE-SENSITIVE-GROUP2 |
-      | case-sensitive-group3 |
-      | CASE-SENSITIVE-GROUP3 |
-    And these groups should not exist:
-      | groupname             |
-      | CASE-SENSITIVE-GROUP1 |
-      | case-sensitive-group2 |
-      | Case-Sensitive-Group3 |
-
-  @issue-31015 @skipOnOcV10 @toImplementOnOCIS
-  Scenario: admin creates a group with a forward-slash in the group name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    Then the OCS status code of responses on all endpoints should be "100"
-    And the HTTP status code of responses on all endpoints should be "200"
-    And these groups should exist:
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-
-  # A group name must not end in "/subadmins" because that would create ambiguity
-  # with the endpoint for getting the subadmins of a group
-  @issue-31015 @skipOnOcV10 @notToImplementOnOCIS
-  Scenario: admin tries to create a group with name ending in "/subadmins"
-    Given group "brand-new-group" has been created
-    When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And group "priv/subadmins" should not exist
-
-
-  Scenario: admin tries to create a group that already exists
-    Given group "brand-new-group" has been created
-    When the administrator sends a group creation request for group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And group "brand-new-group" should exist
-
-  @issue-31276 @skipOnOcV10
-  Scenario: normal user tries to create a group
-    Given user "brand-new-user" has been created with default attributes and without skeleton files
-    When user "brand-new-user" tries to send a group creation request for group "brand-new-group" using the provisioning API
-    Then the OCS status code should be "401"
-    And the HTTP status code should be "401"
-    And group "brand-new-group" should not exist
-
-  @notToImplementOnOCIS
-  Scenario: subadmin tries to create a group
-    Given user "subadmin" has been created with default attributes and without skeleton files
-    And group "brand-new-group" has been created
-    And user "subadmin" has been made a subadmin of group "brand-new-group"
-    When user "subadmin" tries to send a group creation request for group "another-new-group" using the provisioning API
-    Then the OCS status code should be "997"
-    And the HTTP status code should be "401"
-    And group "another-new-group" should not exist
-
-
-  Scenario: admin tries to create a group that has white space at the end of the name
-    When the administrator sends a group creation request for group "white-space-at-end " using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And group "white-space-at-end " should not exist
-    And group "white-space-at-end" should not exist
-
-
-  Scenario: admin tries to create a group that has white space at the start of the name
-    When the administrator sends a group creation request for group " white-space-at-start" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And group " white-space-at-start" should not exist
-    And group "white-space-at-start" should not exist
-
-
-  Scenario: admin tries to create a group that is a single space
-    When the administrator sends a group creation request for group " " using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"
-    And group " " should not exist
-
-
-  Scenario: admin tries to create a group that is the empty string
-    When the administrator tries to send a group creation request for group "" using the provisioning API
-    Then the OCS status code should be "400"
-    And the HTTP status code should be "400"

tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature

@@ -1,56 +0,0 @@
-@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph
-Feature: add groups
-  As an admin
-  I want to be able to add groups
-  So that I can more easily manage access to resources by groups rather than individual users
-
-  Background:
-    Given using OCS API version "2"
-
-    # Note: these groups do get created OK, but:
-    # 1) the "should exist" step fails because the API to check their existence does not work.
-    # 2) the ordinary group deletion in AfterScenario does not work, because the
-    #    group-delete API does not work for groups with a slash in the name
-  @issue-31015
-  Scenario: admin creates a group with a forward-slash in the group name
-    When the administrator sends a group creation request for the following groups using the provisioning API
-      | groupname        | comment                            |
-      | Mgmt/Sydney      | Slash (special escaping happens)   |
-      | Mgmt//NSW/Sydney | Multiple slash                     |
-      | var/../etc       | using slash-dot-dot                |
-      | priv/subadmins/1 | Subadmins mentioned not at the end |
-    Then the OCS status code of responses on all endpoints should be "200"
-    And the HTTP status code of responses on all endpoints should be "200"
-    # After fixing issue-31015, change the following step to "should exist"
-    And the following groups should not exist
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-    #And group "<group_id>" should exist
-    #
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, remove the following step:
-    And the administrator deletes the following groups using the occ command
-      | groupname        |
-      | Mgmt/Sydney      |
-      | Mgmt//NSW/Sydney |
-      | var/../etc       |
-      | priv/subadmins/1 |
-
-  # A group name must not end in "/subadmins" because that would create ambiguity
-  # with the endpoint for getting the subadmins of a group
-  @issue-31015
-  Scenario: admin tries to create a group with name ending in "/subadmins"
-    Given group "brand-new-group" has been created
-    When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API
-    # After fixing issue-31015, change the expected status to "400"
-    Then the OCS status code should be "200"
-    #Then the OCS status code should be "400"
-    And the HTTP status code should be "200"
-    #And the HTTP status code should be "400"
-    And group "priv/subadmins" should not exist
-    # The following step is needed so that the group does get cleaned up.
-    # After fixing issue-31015, remove the following step:
-    And the administrator deletes group "priv/subadmins" using the occ command