diff --git a/.drone.star b/.drone.star index 6a1f02a8b5..d00dea0193 100644 --- a/.drone.star +++ b/.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), diff --git a/Makefile b/Makefile index bac62842da..d9e993d8ea 100644 --- a/Makefile +++ b/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 diff --git a/tests/TestHelpers/LoggingHelper.php b/tests/TestHelpers/LoggingHelper.php new file mode 100644 index 0000000000..574527ef8c --- /dev/null +++ b/tests/TestHelpers/LoggingHelper.php @@ -0,0 +1,457 @@ + + * @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 + * + */ +namespace TestHelpers; + +use Exception; +use InvalidArgumentException; + +/** + * Helper to read and analyze the owncloud log file + * + * @author Artur Neumann + * + */ +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; + } +} diff --git a/tests/acceptance/config/behat-core.yml b/tests/acceptance/config/behat-core.yml index 962cc29369..5807819908 100644 --- a/tests/acceptance/config/behat-core.yml +++ b/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: diff --git a/tests/acceptance/features/bootstrap/LoggingContext.php b/tests/acceptance/features/bootstrap/LoggingContext.php new file mode 100644 index 0000000000..c361da5202 --- /dev/null +++ b/tests/acceptance/features/bootstrap/LoggingContext.php @@ -0,0 +1,617 @@ + + * @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 + * + */ + +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"]; + } +} diff --git a/tests/acceptance/features/bootstrap/ShareesContext.php b/tests/acceptance/features/bootstrap/ShareesContext.php new file mode 100644 index 0000000000..1bd1f7dfb1 --- /dev/null +++ b/tests/acceptance/features/bootstrap/ShareesContext.php @@ -0,0 +1,231 @@ + + * @author Sergio Bertolin + * @author Phillip Davis + * @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 + * + */ + +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'); + } +} diff --git a/tests/acceptance/features/bootstrap/WebDavLockingContext.php b/tests/acceptance/features/bootstrap/WebDavLockingContext.php new file mode 100644 index 0000000000..dc9b92e2f9 --- /dev/null +++ b/tests/acceptance/features/bootstrap/WebDavLockingContext.php @@ -0,0 +1,700 @@ + + * @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 + * + */ + +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 + = "" . + " "; + $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 .= ""; + } + } + + $body .= ""; + $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 + = "" . + " " . + "" . + ""; + $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'); + } +} diff --git a/tests/acceptance/features/coreApiAuth/cors.feature b/tests/acceptance/features/coreApiAuth/cors.feature deleted file mode 100644 index ca0c21ef6d..0000000000 --- a/tests/acceptance/features/coreApiAuth/cors.feature +++ /dev/null @@ -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 "" - 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 "" with headers - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers using password "invalid" - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers using password "invalid" - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 | diff --git a/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature b/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature deleted file mode 100644 index a3ece05bac..0000000000 --- a/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature +++ /dev/null @@ -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 "" - 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 "" with headers using password "invalid" - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 "" - 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 "" with headers using password "invalid" - | header | value | - | Origin | https://aphno.badal | - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 | diff --git a/tests/acceptance/features/coreApiAuth/filesAppAuth.feature b/tests/acceptance/features/coreApiAuth/filesAppAuth.feature deleted file mode 100644 index d4636b295e..0000000000 --- a/tests/acceptance/features/coreApiAuth/filesAppAuth.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuth/tokenAuth.feature b/tests/acceptance/features/coreApiAuth/tokenAuth.feature deleted file mode 100644 index cef3c2bbee..0000000000 --- a/tests/acceptance/features/coreApiAuth/tokenAuth.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature deleted file mode 100644 index e185ae4697..0000000000 --- a/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature deleted file mode 100644 index df7fb37012..0000000000 --- a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature deleted file mode 100644 index 6d1b225a0c..0000000000 --- a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature deleted file mode 100644 index 3f1f08b82c..0000000000 --- a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature b/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature deleted file mode 100644 index bdbe04add8..0000000000 --- a/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature deleted file mode 100644 index d22c87f0e2..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature deleted file mode 100644 index 300645bfd8..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature deleted file mode 100644 index 7f25de041d..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature deleted file mode 100644 index 1c10e382d2..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature +++ /dev/null @@ -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" \ No newline at end of file diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature deleted file mode 100644 index 76f8816e6b..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature deleted file mode 100644 index da98171ce5..0000000000 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiComments/comments.feature b/tests/acceptance/features/coreApiComments/comments.feature deleted file mode 100644 index 20641d996a..0000000000 --- a/tests/acceptance/features/coreApiComments/comments.feature +++ /dev/null @@ -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 | diff --git a/tests/acceptance/features/coreApiComments/createComments.feature b/tests/acceptance/features/coreApiComments/createComments.feature deleted file mode 100644 index c22b7a108d..0000000000 --- a/tests/acceptance/features/coreApiComments/createComments.feature +++ /dev/null @@ -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 "" 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 | | - 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 | diff --git a/tests/acceptance/features/coreApiComments/deleteComments.feature b/tests/acceptance/features/coreApiComments/deleteComments.feature deleted file mode 100644 index 70094c7299..0000000000 --- a/tests/acceptance/features/coreApiComments/deleteComments.feature +++ /dev/null @@ -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 "" 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" diff --git a/tests/acceptance/features/coreApiComments/editComments.feature b/tests/acceptance/features/coreApiComments/editComments.feature deleted file mode 100644 index 49eed785a1..0000000000 --- a/tests/acceptance/features/coreApiComments/editComments.feature +++ /dev/null @@ -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 "" 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 | | - 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 | diff --git a/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature b/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature deleted file mode 100644 index 2262639eb4..0000000000 --- a/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature +++ /dev/null @@ -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 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 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 | diff --git a/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature b/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature deleted file mode 100644 index 58792f5173..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiFederationToRoot1/federated.feature b/tests/acceptance/features/coreApiFederationToRoot1/federated.feature deleted file mode 100644 index 222fe003ce..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot1/federated.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - And the HTTP status code should be "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - When user "Brian" deletes the last pending federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - 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 "" - 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 "" - 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 "" - When user "UNAUTHORIZED_USER" requests shared secret using the federation API - Then the HTTP status code should be "" - 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 "" - And user "Brian" retrieves the information of the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - And user "Brian" retrieves the information of the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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" diff --git a/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature b/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature deleted file mode 100644 index 54aa5319e1..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature +++ /dev/null @@ -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 "" - 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 "" - 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 | diff --git a/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature b/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature deleted file mode 100644 index 885f13e026..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiFederationToRoot2/federated.feature b/tests/acceptance/features/coreApiFederationToRoot2/federated.feature deleted file mode 100644 index d117cd0581..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot2/federated.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - When user "Brian" deletes the last share using the sharing API - And using server "REMOTE" - Then the OCS status code should be "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" 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 "" - 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 "" 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 "" 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 "" - 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 "" 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 "" - 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - - 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 "" - 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 "" - 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 "" - 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 "" - 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 diff --git a/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature b/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature deleted file mode 100644 index 9db6ed73e5..0000000000 --- a/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature b/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature deleted file mode 100644 index 84f56851c3..0000000000 --- a/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiFederationToShares1/federated.feature b/tests/acceptance/features/coreApiFederationToShares1/federated.feature deleted file mode 100644 index 4e2cec9138..0000000000 --- a/tests/acceptance/features/coreApiFederationToShares1/federated.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - 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 "" - When user "Brian" gets the list of pending federated cloud shares using the sharing API - Then the OCS status code should be "" - 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 "" - When user "Brian" retrieves the information of the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - And the HTTP status code should be "" - 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 "" - When user "Brian" from server "LOCAL" accepts the last pending share using the sharing API - Then the OCS status code should be "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - When user "Brian" deletes the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - 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 "" - When user "Brian" deletes the last pending federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - 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 "" - When user "UNAUTHORIZED_USER" requests shared secret using the federation API - Then the HTTP status code should be "" - 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 "" - And user "Brian" retrieves the information of the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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 "" - And user "Brian" retrieves the information of the last federated cloud share using the sharing API - Then the OCS status code should be "" - 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" diff --git a/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature b/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature deleted file mode 100644 index 3d7c5063c3..0000000000 --- a/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | diff --git a/tests/acceptance/features/coreApiFederationToShares2/federated.feature b/tests/acceptance/features/coreApiFederationToShares2/federated.feature deleted file mode 100644 index fe4ecd8a08..0000000000 --- a/tests/acceptance/features/coreApiFederationToShares2/federated.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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," 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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 "" - 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 "" - 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 "" 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - 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 "" - - 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 "" - 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 "" - 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 "" - 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 "" - 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 | diff --git a/tests/acceptance/features/coreApiMain/appManagement.feature b/tests/acceptance/features/coreApiMain/appManagement.feature deleted file mode 100644 index 72bc31d8e1..0000000000 --- a/tests/acceptance/features/coreApiMain/appManagement.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiMain/caldav.feature b/tests/acceptance/features/coreApiMain/caldav.feature deleted file mode 100644 index aabfd038b9..0000000000 --- a/tests/acceptance/features/coreApiMain/caldav.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiMain/carddav.feature b/tests/acceptance/features/coreApiMain/carddav.feature deleted file mode 100644 index 8765e3a10e..0000000000 --- a/tests/acceptance/features/coreApiMain/carddav.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature b/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature deleted file mode 100644 index a09875b9fa..0000000000 --- a/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiMain/external-storage.feature b/tests/acceptance/features/coreApiMain/external-storage.feature deleted file mode 100644 index 4b1a7e0576..0000000000 --- a/tests/acceptance/features/coreApiMain/external-storage.feature +++ /dev/null @@ -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 "" - And user "Alice" has been created with default attributes and small skeleton files - When user "Alice" sends HTTP method "GET" to OCS API endpoint "" - Then the OCS status code should be "" - And the HTTP status code should be "" - 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 | diff --git a/tests/acceptance/features/coreApiMain/quota.feature b/tests/acceptance/features/coreApiMain/quota.feature deleted file mode 100644 index f77285b557..0000000000 --- a/tests/acceptance/features/coreApiMain/quota.feature +++ /dev/null @@ -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 "" - And the quota of user "Alice" has been set to "10 MB" - And user "Alice" has uploaded file with 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 "" - 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 "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 diff --git a/tests/acceptance/features/coreApiMain/userSync.feature b/tests/acceptance/features/coreApiMain/userSync.feature deleted file mode 100644 index 01a787b8ed..0000000000 --- a/tests/acceptance/features/coreApiMain/userSync.feature +++ /dev/null @@ -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 "" - 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 "" - 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 "" - When the administrator tries to sync user "nonexistentuser" using the OCS API - Then the HTTP status code should be "" - 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 "" - 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 "" - When user "Alice" tries to sync user "Brian" using the OCS API - Then the HTTP status code should be "" - And the OCS status code should be "" - 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 "" - 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 | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature deleted file mode 100644 index be2f77df6a..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature +++ /dev/null @@ -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 "" 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 "" - 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 ] | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature deleted file mode 100644 index 95e059d42b..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature deleted file mode 100644 index a6935a77b0..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature deleted file mode 100644 index 3d6ee38b66..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature b/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature deleted file mode 100644 index 3051238bfa..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature deleted file mode 100644 index 4fdf7987b4..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature +++ /dev/null @@ -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 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature deleted file mode 100644 index a10d9b0c45..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature +++ /dev/null @@ -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 | - | | | - When the administrator changes the email of user "" 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 "" 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 "" 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 | | - And the display name of user "brand-new-user" should be "" - 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature b/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature deleted file mode 100644 index a1dbc7a7bc..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature deleted file mode 100644 index df17e2eb8d..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature b/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature deleted file mode 100644 index 9e31e2b1d4..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature b/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature deleted file mode 100644 index df2280d800..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature +++ /dev/null @@ -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 | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature deleted file mode 100644 index ad91ebc2b1..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature deleted file mode 100644 index 211e478bdf..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature +++ /dev/null @@ -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 | - | | | | - When the administrator retrieves the information of user "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the display name returned by the API should be "" - And the email address returned by the API should be "" - 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 "" retrieves the information of user "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the display name returned by the API should be "New User" - And the quota definition returned by the API should be "default" - And the free, used, total and relative quota returned by the API should exist and be valid numbers - And the last login returned by the API should be a current Unix timestamp - Examples: - | username1 | username2 | - | BRAND-NEW-USER | brand-new-user | - | brand-new-user | BRAND-NEW-USER | - - - 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 "" retrieves the information of user "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the display name returned by the API should be "New User" - And the quota definition returned by the API should be "default" - And the free, used, total and relative quota returned by the API should exist and be valid numbers - And the last login returned by the API should be a current Unix timestamp - Examples: - | username1 | username2 | - | Brand-New-User | brand-new-user | - | brand-new-user | Brand-New-User | - - - 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature b/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature deleted file mode 100644 index 35f83722a4..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature deleted file mode 100644 index 7c93818960..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature deleted file mode 100644 index 4ccf8fe40c..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature +++ /dev/null @@ -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 "" 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 "" 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" - diff --git a/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature deleted file mode 100644 index c9d22d7318..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature +++ /dev/null @@ -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 "" 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 "" - 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 ] | diff --git a/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature deleted file mode 100644 index 8fa3094c9b..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature deleted file mode 100644 index 5665306bfc..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature deleted file mode 100644 index d3574ad83c..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature deleted file mode 100644 index a7ccff614c..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature deleted file mode 100644 index 15fd81372e..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature deleted file mode 100644 index 3094b5313e..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature deleted file mode 100644 index 079523c972..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature deleted file mode 100644 index 88548da02a..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature +++ /dev/null @@ -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 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature deleted file mode 100644 index e5c89b61b3..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature deleted file mode 100644 index 957726ae4e..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature +++ /dev/null @@ -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 | - | | | - When the administrator changes the email of user "" 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 "" 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 "" 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 | | - And the display name of user "brand-new-user" should be "" - 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature deleted file mode 100644 index 00294a4857..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature deleted file mode 100644 index 2899caa61f..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature deleted file mode 100644 index 7db56e2e34..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature deleted file mode 100644 index a0a23bdeeb..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature b/tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature deleted file mode 100644 index 9d50443cea..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature b/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature deleted file mode 100644 index 2c35f17a51..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature +++ /dev/null @@ -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 | diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature deleted file mode 100644 index f7cc37c16b..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature deleted file mode 100644 index 469d8e03e9..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUser.feature deleted file mode 100644 index e12ed60c39..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getUser.feature +++ /dev/null @@ -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 | - | | | | - When the administrator retrieves the information of 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 "" - And the email address returned by the API should be "" - 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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature deleted file mode 100644 index 37e9807dc3..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature deleted file mode 100644 index 62142a441e..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature deleted file mode 100644 index 6785226cef..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature deleted file mode 100644 index c70d770f1c..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature deleted file mode 100644 index 4b4d99f131..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature deleted file mode 100644 index db4c8a5fd1..0000000000 --- a/tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature +++ /dev/null @@ -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 "" 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 "" 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" - diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature deleted file mode 100644 index 69f824f3a3..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature deleted file mode 100644 index 4dc0a0051c..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature deleted file mode 100644 index 702631efe7..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature +++ /dev/null @@ -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 "" 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 "" using the provisioning API - When the administrator adds user "brand-new-user" to group "" 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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature deleted file mode 100644 index 8610848173..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature +++ /dev/null @@ -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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" 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 "" has been created - And group "" has been created - And group "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" should not exist - But group "" should exist - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" should not exist - Examples: - | group_id | comment | - | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature deleted file mode 100644 index 7f8e6b9c11..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature +++ /dev/null @@ -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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature deleted file mode 100644 index ffda9e60e6..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature +++ /dev/null @@ -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 "" has been created - When the administrator gets all the members of group "" 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" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature deleted file mode 100644 index f5ece2823d..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature deleted file mode 100644 index dcb80879a2..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature deleted file mode 100644 index c356fc1887..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature +++ /dev/null @@ -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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature deleted file mode 100644 index c37e0117a6..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature +++ /dev/null @@ -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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature deleted file mode 100644 index e735b9a0d7..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature +++ /dev/null @@ -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 "" has been created - And group "" has been created - And group "" has been created - And user "brand-new-user" has been added to group "" - And user "brand-new-user" has been added to group "" - And user "brand-new-user" has been added to group "" - When the administrator removes user "" from 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 "" - But user "brand-new-user" should belong to group "" - And user "brand-new-user" should belong to group "" - 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 "" has been created - And user "brand-new-user" has been added to group "" - When the administrator removes user "brand-new-user" from 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 "" - Examples: - | group_id | comment | - | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature deleted file mode 100644 index 3b9a86f7dc..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature +++ /dev/null @@ -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 "" 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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature deleted file mode 100644 index df0109291c..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature +++ /dev/null @@ -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" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature deleted file mode 100644 index 81c4d867f5..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature +++ /dev/null @@ -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 "" 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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature deleted file mode 100644 index bc20a5f165..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature +++ /dev/null @@ -1,17 +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" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - And group "brand-new-group" should not exist diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature deleted file mode 100644 index 4d8426f026..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature +++ /dev/null @@ -1,219 +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 "2" - - @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 | comment | - | simplegroup | nothing special here | - | Espa├▒a┬з├а├┤┼УтВм | special European and other characters | - | рдиреЗрдкрд╛рд▓реА | Unicode group name | - When the administrator adds the following users to the following groups using the provisioning API - | username | groupname | - | brand-new-user | simplegroup | - | brand-new-user | Espa├▒a┬з├а├┤┼УтВм | - | brand-new-user | рдиреЗрдкрд╛рд▓реА | - 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" - - @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 "200" - 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 "200" - And the HTTP status code of responses on all endpoints should be "200" - - @issue-31015 @skipOnOcV10 - 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 - 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 | - 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 "200" - And the HTTP status code of responses on all endpoints should be "200" - - @skipOnLDAP @toImplementOnOCIS @issue-product-283 - 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 "200" - 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 | - - @issue-31276 @skipOnLDAP @skipOnOcV10 - 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 "401" - 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 "400" - And the HTTP status code should be "400" - 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 "400" - And the HTTP status code should be "400" - 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 "400" - And the HTTP status code should be "400" - And the API should not return any data - - @skipOnLDAP @notToImplementOnOCIS - Scenario: subadmin adds 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 "403" - And the HTTP status code should be "403" - And user "brand-new-user" should not belong to group "brand-new-group" - - @skipOnLDAP @notToImplementOnOCIS - Scenario: subadmin tries to add user 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 "403" - And the HTTP status code should be "403" - 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 "200" - 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 "" using the provisioning API - When the administrator adds user "brand-new-user" to group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - Examples: - | group_id | comment | - | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature deleted file mode 100644 index 9e2d0b6a62..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature +++ /dev/null @@ -1,36 +0,0 @@ -@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @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 "2" - - @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" - 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 | - #And group "" has been created - And 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 | var/../etc | - | brand-new-user | priv/subadmins/1 | - 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" - # 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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature deleted file mode 100644 index 85c2201eda..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature +++ /dev/null @@ -1,17 +0,0 @@ -@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @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 "2" - - @issue-31276 @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 OCS status code should be "401" - And the HTTP status code should be "401" - And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroup.feature deleted file mode 100644 index 18082a0a35..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroup.feature +++ /dev/null @@ -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 "2" - - @smokeTest - Scenario Outline: admin deletes a group - Given group "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - And group "" 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 @issue-product-283 - Scenario Outline: group names are case-sensitive, the correct group is deleted - Given group "" has been created - And group "" has been created - And group "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - And group "" should not exist - But group "" should exist - And group "" 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 "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "200" - And the HTTP status code should be "200" - And group "" 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 | - - @issue-31276 @skipOnOcV10 - 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 "401" - And the HTTP status code should be "401" - And group "brand-new-group" should exist - - @issue-31276 @skipOnOcV10 @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 "401" - And the HTTP status code should be "401" - And group "brand-new-group" should exist - - @issue-31015 @skipOnOcV10 @toImplementOnOCIS @issue-product-284 - Scenario Outline: admin deletes a group that has a forward-slash in the group name - Given group "" has been created - When the administrator deletes group "" using the provisioning API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And group "" should not exist - Examples: - | group_id | comment | - | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature deleted file mode 100644 index b4ec5e4ce9..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature +++ /dev/null @@ -1,43 +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 "2" - - @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" - 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 | - #Given group "" has been created - And 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 "200" - #Then the OCS status code should be "200" - 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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature deleted file mode 100644 index 8d694b23da..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature +++ /dev/null @@ -1,30 +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 "2" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - And group "brand-new-group" should exist - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - And group "brand-new-group" should exist diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature deleted file mode 100644 index c2fdffeb7b..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature +++ /dev/null @@ -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 "2" - - @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 "200" - 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 "200" - 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 "404" - And the HTTP status code should be "404" - - @toImplementOnOCIS @issue-product-283 - Scenario Outline: admin tries to get users in a group but using wrong case of the group name - Given group "" has been created - When the administrator gets all the members of group "" using the provisioning API - Then the OCS status code should be "404" - And the HTTP status code should be "404" - 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 "200" - And the HTTP status code should be "200" - And the users returned by the API should be - | Alice | - | Brian | - - @issue-31276 @skipOnOcV10 @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 "401" - And the HTTP status code should be "401" - - @issue-31276 @skipOnOcV10 - 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 "401" - And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature deleted file mode 100644 index 357cd66f1a..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature +++ /dev/null @@ -1,28 +0,0 @@ -@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @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 "2" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature deleted file mode 100644 index 01507e6db5..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature +++ /dev/null @@ -1,60 +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 "2" - - @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 HTTP status code should be "200" - And the OCS status code should be "200" - And 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 HTTP status code should be "200" - And the OCS status code should be "200" - And 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 "200" - 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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature deleted file mode 100644 index 1aaddf1302..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature +++ /dev/null @@ -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 "2" - - @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 "200" - 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 "404" - And the HTTP status code should be "404" - 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 "200" - 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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature deleted file mode 100644 index 8b5153bb93..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature +++ /dev/null @@ -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 "2" - - @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 "200" - 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 groups returned by the API should be - | Mgmt/Sydney | - | var/../etc | - | priv/subadmins/1 | - And the OCS status code should be "200" - And the HTTP status code should be "200" - - @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 "200" - 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" - - @issue-31276 @skipOnOcV10 - 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 "401" - 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 "200" - 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 "200" - 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 "200" - 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 "200" - 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 "200" - And the HTTP status code should be "200" - And the groups returned by the API should be - | group1 | - | group2 | - | users | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature deleted file mode 100644 index e29f0e0446..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature +++ /dev/null @@ -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 "2" - - @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 groups returned by the API should be - | Mgmt/Sydney | - | var/../etc | - | priv/subadmins/1 | - And the OCS status code should be "200" - And the HTTP status code should be "200" - # 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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature deleted file mode 100644 index 43fe85f81f..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature +++ /dev/null @@ -1,22 +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 "2" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature deleted file mode 100644 index d499f6e8fa..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature +++ /dev/null @@ -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 "2" - - @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 "200" - 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 "200" - 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 @issue-product-284 - 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 "200" - 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 "200" - 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 @issue-product-283 - 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 "" has been created - And group "" has been created - And group "" has been created - And user "brand-new-user" has been added to group "" - And user "brand-new-user" has been added to group "" - And user "brand-new-user" has been added to group "" - When the administrator removes user "" from 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 belong to group "" - But user "brand-new-user" should belong to group "" - And user "brand-new-user" should belong to group "" - 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 "400" - And the HTTP status code should be "400" - 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 "200" - 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 "403" - And the HTTP status code should be "403" - And user "brand-new-user" should belong to group "brand-new-group" - - @issue-31276 @skipOnOcV10 - 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 "401" - 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 @issue-product-284 - 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 "" has been created - And user "brand-new-user" has been added to group "" - When the administrator removes user "brand-new-user" from 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 belong to group "" - Examples: - | group_id | comment | - | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature deleted file mode 100644 index dc5c83ce12..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature +++ /dev/null @@ -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 "2" - - @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 "" 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 "200" - 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 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature deleted file mode 100644 index 9199f32115..0000000000 --- a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature +++ /dev/null @@ -1,23 +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 "2" - - @issue-31276 - 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 OCS status code should be "401" - And the HTTP status code should be "401" - And user "another-new-user" should belong to group "brand-new-group" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature deleted file mode 100644 index 281eaa9573..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature +++ /dev/null @@ -1,873 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: a default expiration date can be specified for shares with users or groups - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - - Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares without specifying expireDate - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" should include - | expiration | | - And the response when user "Brian" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings - | path | /FOLDER | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +15 days | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | %username% | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings - | path | /FOLDER | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +15 days | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | %username% | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - And user "Alice" has created a share with settings - | path | /FOLDER | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +15 days | - When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | %username% | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - And user "Alice" has created a share with settings - | path | /FOLDER | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | %username% | - | expiration | +7 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +7 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" should include - | expiration | | - And the response when user "Brian" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings - | path | /FOLDER | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +15 days | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | grp1 | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings - | path | /FOLDER | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +15 days | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | grp1 | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "FOLDER" - And user "Alice" has created a share with settings - | path | /FOLDER | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +15 days | - When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +15 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +15 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "FOLDER" - And user "Alice" has created a share with settings - | path | /FOLDER | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +3 days | - When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +3 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +3 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /textfile0.txt | - | uid_owner | %username% | - | share_with | %username% | - | expiration | +7 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +7 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +10 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Cannot set expiration date more than 7 days in the future" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares without setting expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /textfile0.txt | - | uid_owner | %username% | - | share_with | %username% | - | expiration | +30 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +30 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date set, user shares with expiration date more than the max expire date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +40 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Cannot set expiration date more than 30 days in the future" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares and changes the max expire date greater than the previous one - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And 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" with permissions "read,share" - When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40" - Then the info about the last share by user "Alice" with user "Brian" should include - | expiration | +30 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled for users/max expire date is set, user shares and changes max expire date less than the previous one - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And 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" with permissions "read,share" - When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with user "Brian" should include - | expiration | +30 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /textfile0.txt | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +7 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +7 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +10 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Cannot set expiration date more than 7 days in the future" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date is set, user shares without setting expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /textfile0.txt | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +30 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +30 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date set, user shares with expiration date more than the max expire date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | shareWith | grp1 | - | permissions | read,share | - | expireDate | +40 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Cannot set expiration date more than 30 days in the future" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes the max expire date greater than the previous one - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" - When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40" - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with user "Brian" should include - | expiration | +30 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +30 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes max expire date less than the previous one - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" - When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15" - Then the HTTP status code should be "200" - And the response when user "Alice" gets the info of the last share should include - | expiration | +30 days | - And the response when user "Brian" gets the info of the last share should include - | expiration | +30 days | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "FOLDER" - When user "Alice" shares file "FOLDER" with group "grp1" with permissions "read,share" using the sharing API - Then the HTTP status code should be "200" - And the info about the last share by user "Alice" with group "grp1" should include - | expiration | | - And the response when user "Brian" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - When user "Alice" shares file "/FOLDER" with user "Brian" with permissions "read,share" using the sharing API - Then the info about the last share by user "Alice" with user "Brian" should include - | expiration | | - And the response when user "Brian" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | INVALID-DATE | - Then the HTTP status code should be "" - And the OCS status code should be "" - And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 404 | 200 | - | 2 | 404 | 404 | - - - Scenario Outline: sharing with default expiration date enforced for users, user shares with different time format - Given using OCS API version "2" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | | - Then the HTTP status code should be "200" - And the OCS status code should be "200" - And the fields of the last response to user "Alice" should include - | expiration | 2050-12-11 | - And the response when user "Brian" gets the info of the last share should include - | expiration | 2050-12-11 | - Examples: - | date | - | 2050-12-11 | - | 11-12-2050 | - | 12/11/2050 | - | 11.12.2050 | - | 11.12.2050 12:30:40 | - - - Scenario Outline: user shares with humanized expiration date format - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" should include - | expiration | | - And the response when user "Brian" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | expiration_date | default | enforce | ocs_status_code | - | 1 | today | yes | yes | 100 | - | 2 | today | yes | yes | 200 | - | 1 | tomorrow | yes | yes | 100 | - | 2 | tomorrow | yes | yes | 200 | - | 1 | today | yes | no | 100 | - | 2 | today | yes | no | 200 | - | 1 | tomorrow | yes | no | 100 | - | 2 | tomorrow | yes | no | 200 | - | 1 | today | no | no | 100 | - | 2 | today | no | no | 200 | - | 1 | tomorrow | no | no | 100 | - | 2 | tomorrow | no | no | 200 | - - - Scenario Outline: user shares with humanized expiration date format in past - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | yesterday | - Then the HTTP status code should be "" - And the OCS status code should be "" - And the OCS status message should be "Expiration date is in the past" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | ocs_status_code | http_status_code | default | enforce | - | 1 | 404 | 200 | yes | yes | - | 2 | 404 | 404 | yes | yes | - | 1 | 404 | 200 | yes | no | - | 2 | 404 | 404 | yes | no | - | 1 | 404 | 200 | no | no | - | 2 | 404 | 404 | no | no | - - - Scenario Outline: user shares with invalid humanized expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | 123 | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | default | enforce | - | 1 | 200 | yes | yes | - | 2 | 404 | yes | yes | - | 1 | 200 | yes | no | - | 2 | 404 | yes | no | - | 1 | 200 | no | no | - | 2 | 404 | no | no | - - - Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDateAsString | -10 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the OCS status message should be "Expiration date is in the past" - And user "Brian" should not have any received shares - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @issue-36569 - Scenario Outline: sharing with default expiration date enforced for users, max expire date is 0, user shares without specifying expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "0" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" should include - | expiration | today | - And the response when user "Brian" gets the info of the last share should include - | expiration | today | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "1" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the fields of the last response to user "Alice" should include - | expiration | tomorrow | - And the response when user "Brian" gets the info of the last share should include - | expiration | tomorrow | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario: accessing a user share that is expired should not be possible - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has created a share with settings - | path | /textfile0.txt | - | shareType | user | - | shareWith | Brian | - | expireDate | +15 days | - And the administrator has expired the last created share using the testing API - When user "Alice" 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 "200" - And user "Alice" should not see the share id of the last share - And user "Brian" should not see the share id of the last share - And as "Brian" file "/textfile0.txt" should not exist - And as "Alice" file "/textfile0.txt" should exist - - - Scenario: accessing a group share that is expired should not be possible - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - And group "brand-new-group" has been created - And user "Brian" has been added to group "brand-new-group" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has created a share with settings - | path | /textfile0.txt | - | shareType | group | - | shareWith | brand-new-group | - | expireDate | +15 days | - And the administrator has expired the last created share using the testing API - When user "Alice" 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 "200" - And user "Alice" should not see the share id of the last share - And user "Brian" should not see the share id of the last share - And as "Brian" file "/textfile0.txt" should not exist - And as "Alice" file "/textfile0.txt" should exist - - - Scenario: accessing a link share that is expired should not be possible - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - And group "brand-new-group" has been created - And user "Brian" has been added to group "brand-new-group" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has created a public link share with settings - | path | /textfile0.txt | - | shareWith | brand-new-group | - | expireDate | +15 days | - And the administrator has expired the last created public link share using the testing API - When the public accesses the preview of file "textfile0.txt" from the last shared public link using the sharing API - Then the HTTP status code should be "404" - And as "Alice" file "/textfile0.txt" should exist - - - Scenario Outline: sharing file with edit permissions - Given using OCS API version "" - And auto-accept shares has been disabled - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "Random data" to "/file.txt" - When user "Alice" creates a share using the sharing API with settings - | path | file.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,update | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | item_type | file | - | mimetype | text/plain | - | share_type | user | - | file_target | /file.txt | - | uid_owner | %username% | - | share_with | %username% | - | permissions | read,update | - When user "Brian" accepts share "/file.txt" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Brian" uploads the following files with content "new content" - | path | - | /file.txt | - Then the content of the following files for user "Brian" should be "new content" - | path | - | /file.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature deleted file mode 100644 index ada9235ab2..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature +++ /dev/null @@ -1,181 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share resources where the sharee receives the share in multiple ways - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - - Scenario Outline: Creating a new share with user who already received a share through their group - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - When user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share of folder and sub-folder to same user - core#20645 - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp4" has been created - And user "Brian" has been added to group "grp4" - And user "ALice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API - Then the OCS status code of responses on all endpoints should be "" - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - | /CHILD/ | - | /CHILD/child.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing subfolder when parent already shared - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Alice" has created folder "/test" - And user "Alice" has created folder "/test/sub" - And user "Alice" has shared folder "/test" with group "grp1" - When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" folder "/sub" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing subfolder when parent already shared with group of sharer - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp0" has been created - And user "Alice" has been added to group "grp0" - And user "Alice" has created folder "/test" - And user "Alice" has created folder "/test/sub" - And user "Alice" has shared folder "/test" with group "grp0" - When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" folder "/sub" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: multiple users share a file with the same name but different permissions to a user - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Brian" has uploaded file with content "First data" to "/randomfile.txt" - And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt" - When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Alice" the info about the last share by user "Brian" with user "Alice" should include - | uid_owner | %username% | - | share_with | %username% | - | file_target | /randomfile.txt | - | item_type | file | - | permissions | read | - When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API - And as "Alice" the info about the last share by user "Carol" with user "Alice" should include - | uid_owner | %username% | - | share_with | %username% | - | file_target | /randomfile (2).txt | - | item_type | file | - | permissions | read,update | - And the content of file "randomfile.txt" for user "Alice" should be "First data" - And the content of file "randomfile (2).txt" for user "Alice" should be "Second data" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: multiple users share a folder with the same name to a user - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Brian" has created folder "/zzzfolder" - And user "Brian" has created folder "zzzfolder/Brian" - And user "Carol" has created folder "/zzzfolder" - And user "Carol" has created folder "zzzfolder/Carol" - When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API - And as "Alice" the info about the last share by user "Brian" with user "Alice" should include - | uid_owner | %username% | - | share_with | %username% | - | file_target | /zzzfolder | - | item_type | folder | - | permissions | read,delete | - When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API - And as "Alice" the info about the last share by user "Carol" with user "Alice" should include - | uid_owner | %username% | - | share_with | %username% | - | file_target | /zzzfolder (2) | - | item_type | folder | - | permissions | read,share | - And as "Alice" folder "zzzfolder/Brian" should exist - And as "Alice" folder "zzzfolder (2)/Carol" should exist - Examples: - | ocs_api_version | - | 1 | - | 2 | - - @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP - Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And these groups have been created: - | groupname | - | grp1 | - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "Shared content" to "lorem.txt" - And user "Carol" has uploaded file with content "My content" to "lorem.txt" - When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API - And the administrator adds user "Carol" to group "grp1" using the provisioning API - Then the OCS status code of responses on all endpoints should be "" - And the HTTP status code of responses on all endpoints should be "200" - And the content of file "lorem.txt" for user "Brian" should be "Shared content" - And the content of file "lorem.txt" for user "Carol" should be "My content" - And the content of file "lorem (2).txt" for user "Carol" should be "Shared content" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature deleted file mode 100644 index 8a61aab58e..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature +++ /dev/null @@ -1,289 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: Sharing resources with different case names with the sharee and checking the coexistence of resources on sharee/receivers side - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario: sharing file with an internal user that has existing files with different case names - Given user "Alice" has uploaded the following files with content "some data" - | path | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - And user "Brian" has uploaded the following files with content "some data" - | path | - | TEXTFILE.txt | - | TEXT_FILE.txt | - | 123TEXTFILE.txt | - | TEXTFILE.xyz.txt | - When user "Alice" shares the following files with user "Brian" using the sharing API - | path | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - 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" the following files should exist - | path | - | TEXTFILE.txt | - | TEXT_FILE.txt | - | 123TEXTFILE.txt | - | TEXTFILE.xyz.txt | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - - - Scenario: sharing folder with an internal user that has existing folders with different case names - Given user "Alice" has created the following folders - | path | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - And user "Brian" has created the following folders - | path | - | /fo/ | - | /f_o/ | - | /123fo/ | - | /fo.xyz/ | - When user "Alice" shares the following folders with user "Brian" using the sharing API - | path | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - 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" the following folders should exist - | path | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - | /fo/ | - | /f_o/ | - | /123fo/ | - | /fo.xyz/ | - - - Scenario: sharing file with an internal user that has existing folders with different case names - Given user "Alice" has uploaded the following files with content "some data" - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - And user "Brian" has created the following folders - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - When user "Alice" shares the following files with user "Brian" using the sharing API - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - 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" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - And as "Brian" the following files should exist - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - - - Scenario: sharing folder with an internal user that has existing files with different case names - Given user "Alice" has created the following folders - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - And user "Brian" has uploaded the following files with content "some data" - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - When user "Alice" shares the following folders with user "Brian" using the sharing API - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - 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" the following files should exist - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - And as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - - - Scenario: sharing file with group members that has existing files with different case names - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded the following files with content "some data" - | path | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - And user "Brian" has uploaded the following files with content "some data" - | path | - | TEXTFILE.txt | - | TEXT_FILE.txt | - | 123TEXTFILE.txt | - | TEXTFILE.xyz.txt | - When user "Alice" shares the following files with group "grp1" using the sharing API - | path | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - 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" the following files should exist - | path | - | TEXTFILE.txt | - | TEXT_FILE.txt | - | 123TEXTFILE.txt | - | TEXTFILE.xyz.txt | - | textfile.txt | - | text_file.txt | - | 123textfile.txt | - | textfile.XYZ.txt | - - - Scenario: sharing folder with group members that has existing folders with different case names - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created the following folders - | path | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - And user "Brian" has created the following folders - | path | - | /fo/ | - | /f_o/ | - | /123fo/ | - | /fo.xyz/ | - When user "Alice" shares the following folders with group "grp1" using the sharing API - | path | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - 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" the following folders should exist - | path | - | /fo/ | - | /f_o/ | - | /123fo/ | - | /fo.xyz/ | - | /FO/ | - | /F_O/ | - | /123FO/ | - | /FO.XYZ/ | - - - Scenario: sharing file with group members that has existing folders with different case names - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded the following files with content "some data" - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - And user "Brian" has created the following folders - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - When user "Alice" shares the following files with group "grp1" using the sharing API - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - 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" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - And as "Brian" the following files should exist - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - - - Scenario: sharing folder with group members that has existing files with different case names - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created the following folders - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - And user "Brian" has uploaded the following files with content "some data" - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - When user "Alice" shares the following folders with group "grp1" using the sharing API - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | - 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" the following files should exist - | path | - | casesensitive.txt | - | case_sensitive.txt | - | 123CASE_SENSITIVE.txt | - | casesensitive.xyz.txt | - And as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature deleted file mode 100644 index 8c85193eeb..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature +++ /dev/null @@ -1,22 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: resources shared with the same name are received with unique names - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - - @smokeTest - Scenario: unique target names for incoming shares - Given user "Alice" has created folder "/foo" - And user "Brian" has created folder "/foo" - When user "Alice" shares folder "/foo" with user "Carol" using the sharing API - And user "Brian" shares folder "/foo" 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" - And user "Carol" should see the following elements - | /foo/ | - | /foo (2)/ | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature deleted file mode 100644 index 7837ce77c6..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature +++ /dev/null @@ -1,83 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: cannot share resources when in a group that is excluded from sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: user who is excluded from sharing tries to share a file with another user - Given using OCS API version "" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' - When user "Brian" shares file "fileToShare.txt" with user "Alice" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And as "Alice" file "fileToShare.txt" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: user who is excluded from sharing tries to share a file with a group - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And these groups have been created: - | groupname | - | grp1 | - | grp2 | - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp2" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" - When user "Brian" shares file "fileToShare.txt" with group "grp2" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And as "Carol" file "fileToShare.txt" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: user who is excluded from sharing tries to share a folder with another user - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' - And user "Brian" has created folder "folderToShare" - When user "Brian" shares folder "folderToShare" with user "Alice" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And as "Alice" folder "folderToShare" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: user who is excluded from sharing tries to share a folder with a group - Given using OCS API version "" - And group "grp0" has been created - And group "grp1" has been created - And user "Alice" has been added to group "grp0" - And user "Brian" has been added to group "grp1" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp0"]' - And user "Alice" has created folder "folderToShare" - When user "Alice" shares folder "folderToShare" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And as "Brian" folder "folderToShare" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature deleted file mode 100644 index 2ff8c3cffe..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature +++ /dev/null @@ -1,21 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: shares are received in the default folder for received shares - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - - Scenario Outline: Do not allow sharing of the entire share_folder - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And the administrator has set the default folder for received shares to "" - And user "Alice" has created folder "FOLDER" - And user "Alice" has shared folder "/FOLDER" with user "Brian" - And user "Brian" has unshared folder "ReceivedShares/FOLDER" - When user "Brian" shares folder "/ReceivedShares" with user "Alice" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | share_folder | - | 1 | 200 | /ReceivedShares | - | 2 | 404 | /ReceivedShares | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature deleted file mode 100644 index 6c7679911f..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature +++ /dev/null @@ -1,82 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing works when a username and group name are the same - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" - - @skipOnLDAP - Scenario: creating a new share with user and a group having same name - Given these users have been created without skeleton files: - | username | - | Brian | - | Carol | - And group "Brian" has been created - And user "Carol" has been added to group "Brian" - And user "Alice" has shared file "randomfile.txt" with group "Brian" - When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /randomfile.txt | - And user "Carol" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "Brian" should be "Random data" - And the content of file "randomfile.txt" for user "Carol" should be "Random data" - - @skipOnLDAP - Scenario: creating a new share with group and a user having same name - Given these users have been created without skeleton files: - | username | - | Brian | - | Carol | - And group "Brian" has been created - And user "Carol" has been added to group "Brian" - And user "Alice" has shared file "randomfile.txt" with user "Brian" - When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /randomfile.txt | - And user "Carol" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "Brian" should be "Random data" - And the content of file "randomfile.txt" for user "Carol" should be "Random data" - - @skipOnLDAP - Scenario: creating a new share with user and a group having same name but different case - Given these users have been created without skeleton files: - | username | - | Brian | - | Carol | - And group "Brian" has been created - And user "Carol" has been added to group "Brian" - And user "Alice" has shared file "randomfile.txt" with group "Brian" - When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /randomfile.txt | - And user "Carol" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "Brian" should be "Random data" - And the content of file "randomfile.txt" for user "Carol" should be "Random data" - - @skipOnLDAP - Scenario: creating a new share with group and a user having same name but different case - Given these users have been created without skeleton files: - | username | - | Brian | - | Carol | - And group "Brian" has been created - And user "Carol" has been added to group "Brian" - And user "Alice" has shared file "randomfile.txt" with user "Brian" - When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Carol" should see the following elements - | /randomfile.txt | - And user "Brian" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "Carol" should be "Random data" - And the content of file "randomfile.txt" for user "Brian" should be "Random data" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature deleted file mode 100644 index 8eece2fb63..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature +++ /dev/null @@ -1,72 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share with groups, group names are case-sensitive - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" - And user "Alice" has uploaded file with content "ownCloud test text file 2" to "/textfile2.txt" - And user "Alice" has uploaded file with content "ownCloud test text file 3" to "/textfile3.txt" - - @skipOnLDAP @issue-ldap-250 - Scenario Outline: group names are case-sensitive, sharing with groups with different upper and lower case names - Given using OCS API version "" - And group "" has been created - And group "" has been created - And group "" has been created - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - | David | - And user "Brian" has been added to group "" - And user "Carol" has been added to group "" - And user "David" has been added to group "" - When user "Alice" shares file "textfile1.txt" with group "" using the sharing API - And user "Alice" shares file "textfile2.txt" with group "" using the sharing API - And user "Alice" shares file "textfile3.txt" with group "" using the sharing API - Then the OCS status code of responses on all endpoints should be "" - And the HTTP status code of responses on all endpoints should be "200" - And the content of file "textfile1.txt" for user "Brian" should be "ownCloud test text file 1" - And the content of file "textfile2.txt" for user "Carol" should be "ownCloud test text file 2" - And the content of file "textfile3.txt" for user "David" should be "ownCloud test text file 3" - Examples: - | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | - | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | - | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | - | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | - | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | - | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | - | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | - - @skipOnLDAP @issue-ldap-250 - Scenario Outline: group names are case-sensitive, sharing with nonexistent groups with different upper and lower case names - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - And group "" has been created - And user "Brian" has been added to group "" - When user "Alice" shares file "textfile1.txt" with group "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" should include - | share_with | | - | file_target | /textfile1.txt | - | path | /textfile1.txt | - | permissions | share,read,update | - | uid_owner | %username% | - And the content of file "textfile1.txt" for user "Brian" should be "ownCloud test text file 1" - When user "Alice" shares file "textfile2.txt" with group "" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - When user "Alice" shares file "textfile3.txt" with group "" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | http_status_code | - | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | 200 | - | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | 200 | - | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | 200 | - | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | 404 | - | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | 404 | - | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | 404 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature deleted file mode 100644 index ef0a517f99..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature +++ /dev/null @@ -1,95 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: cannot share resources outside the group when share with membership groups is enabled - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - And group "grp0" has been created - And user "Alice" has been added to group "grp0" - - - Scenario Outline: sharer should not be able to share a folder to a group which he/she is not member of when share with only member group is enabled - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" folder "/PARENT" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 403 | 200 | - | 2 | 403 | 403 | - - - Scenario Outline: sharer should be able to share a folder to a user who is not member of sharer group when share with only member group is enabled - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - - Scenario Outline: sharer should be able to share a folder to a group which he/she is member of when share with only member group is enabled - Given using OCS API version "" - And user "Brian" has been added to group "grp0" - And user "Alice" has created folder "PARENT" - When user "Alice" shares folder "/PARENT" with group "grp0" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - - Scenario Outline: sharer should not be able to share a file to a group which he/she is not member of when share with only member group is enabled - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" file "/textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 403 | 200 | - | 2 | 403 | 403 | - - - Scenario Outline: sharer should be able to share a file to a group which he/she is member of when share with only member group is enabled - Given using OCS API version "" - And user "Brian" has been added to group "grp0" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/textfile0.txt" with group "grp0" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - - Scenario Outline: sharer should be able to share a file to a user who is not a member of sharer group when share with only member group is enabled - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature deleted file mode 100644 index eb09624101..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature +++ /dev/null @@ -1,27 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share resources with a disabled user - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - - - Scenario Outline: Creating a new share with a disabled user - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has been disabled - When user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "401" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 997 | - - @issue-32068 @skipOnOcV10 - Scenario: Creating a new share with a disabled user - Given using OCS API version "2" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has been disabled - When user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API - Then the OCS status code should be "401" - And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature deleted file mode 100644 index 99c6d479ee..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature +++ /dev/null @@ -1,16 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share resources with a disabled user - current oC10 behavior for issue-32068 - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - - @issue-32068 - Scenario: Creating a new share with a disabled user - Given using OCS API version "2" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has been disabled - When user "Alice" shares file "fileToShare.txt" with user "Brian" 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" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature deleted file mode 100644 index 45a788e175..0000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature +++ /dev/null @@ -1,122 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: cannot share resources with invalid permissions - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: Cannot create a share of a file with invalid permissions - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareWith | Brian | - | shareType | user | - | permissions | | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "/textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | permissions | - | 1 | 400 | 200 | 0 | - | 2 | 400 | 400 | 0 | - | 1 | 404 | 200 | 32 | - | 2 | 404 | 404 | 32 | - - - Scenario Outline: Cannot create a share of a folder with invalid permissions - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - When user "Alice" creates a share using the sharing API with settings - | path | PARENT | - | shareWith | Brian | - | shareType | user | - | permissions | | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "PARENT" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | permissions | - | 1 | 400 | 200 | 0 | - | 2 | 400 | 400 | 0 | - | 1 | 404 | 200 | 32 | - | 2 | 404 | 404 | 32 | - - - Scenario Outline: Cannot create a share of a file with a user with only create permission - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareWith | Brian | - | shareType | user | - | permissions | create | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 400 | 200 | - | 2 | 400 | 400 | - - - Scenario Outline: Cannot create a share of a file with a user with only (create,delete) permission - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareWith | Brian | - | shareType | user | - | permissions | | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | permissions | - | 1 | 400 | 200 | delete | - | 2 | 400 | 400 | delete | - | 1 | 400 | 200 | create,delete | - | 2 | 400 | 400 | create,delete | - - @issue-ocis-reva-34 - Scenario Outline: Cannot create a share of a file with a group with only create permission - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareWith | grp1 | - | shareType | group | - | permissions | create | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 400 | 200 | - | 2 | 400 | 400 | - - @issue-ocis-reva-34 - Scenario Outline: Cannot create a share of a file with a group with only (create,delete) permission - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareWith | grp1 | - | shareType | group | - | permissions | | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | permissions | - | 1 | 400 | 200 | delete | - | 2 | 400 | 400 | delete | - | 1 | 400 | 200 | create,delete | - | 2 | 400 | 400 | create,delete | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature deleted file mode 100644 index 154b87c8e4..0000000000 --- a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature +++ /dev/null @@ -1,109 +0,0 @@ -@api @local_storage @files_external-app-required @files_sharing-app-required @notToImplementOnOCIS -Feature: local-storage - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: Share a file inside a local external storage - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - When user "Alice" shares file "/local_storage/filetoshare.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /filetoshare.txt | - | path | /local_storage/filetoshare.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - And as "Brian" file "/filetoshare.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share a folder inside a local external storage - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - When user "Alice" shares folder "/local_storage/foo" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /foo | - | path | /local_storage/foo | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | user | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: Share a file inside a local external storage to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - When user "Alice" shares file "/local_storage/filetoshare.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /filetoshare.txt | - | path | /local_storage/filetoshare.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share a folder inside a local external storage to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has been added to group "grp1" - And user "Alice" has created folder "/local_storage/foo" - When user "Alice" shares folder "/local_storage/foo" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /foo | - | path | /local_storage/foo | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature deleted file mode 100644 index 8f50be2609..0000000000 --- a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature +++ /dev/null @@ -1,593 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @smokeTest @skipOnEncryptionType:user-keys @issue-32322 - Scenario Outline: Creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16) - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | share_with_user_type | 0 | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest @skipOnEncryptionType:user-keys @issue-32322 - Scenario Outline: Creating a share of a file containing commas in the filename, with a user, the default permissions are read(1)+update(2)+can-share(16) - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "file with comma in filename" to "/sample,1.txt" - When user "Alice" shares file "sample,1.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /sample,1.txt | - | path | /sample,1.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - And the content of file "/sample,1.txt" for user "Brian" should be "file with comma in filename" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Creating a share of a file with a user and asking for various permission combinations - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - Examples: - | ocs_api_version | requested_permissions | granted_permissions | ocs_status_code | - # Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file - | 1 | 31 | 19 | 100 | - | 2 | 31 | 19 | 200 | - # Ask for read, share (17), create and delete. You get share plus read - | 1 | 29 | 17 | 100 | - | 2 | 29 | 17 | 200 | - # Ask for read, update, create, delete. You get read plus update. - | 1 | 15 | 3 | 100 | - | 2 | 15 | 3 | 200 | - # Ask for just update. You get exactly update (you do not get read or anything else) - | 1 | 2 | 2 | 100 | - | 2 | 2 | 2 | 200 | - - - Scenario Outline: Creating a share of a file with no permissions should fail - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "Random data" to "randomfile.txt" - When user "Alice" shares file "randomfile.txt" with user "Brian" with permissions "0" using the sharing API - Then the OCS status code should be "400" - And the HTTP status code should be "" - And as "Brian" file "randomfile.txt" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 400 | - - - Scenario Outline: Creating a share of a folder with no permissions should fail - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/afolder" - When user "Alice" shares folder "afolder" with user "Brian" with permissions "0" using the sharing API - Then the OCS status code should be "400" - And the HTTP status code should be "" - And as "Brian" folder "afolder" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 400 | - - - Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31) - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/FOLDER" - When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /FOLDER | - | path | /FOLDER | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | user | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16) - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Creating a share of a folder with a group, the default permissions are all permissions(31) - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has created folder "/FOLDER" - When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /FOLDER | - | path | /FOLDER | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: Share of folder to a group - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/PARENT" - And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - Then user "Brian" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - And the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - And the OCS status code should be "" - And the HTTP status code should be "200" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing again an own file while belonging to a group - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Brian" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Brian" has shared file "textfile0.txt" with group "grp1" - And user "Brian" has deleted the last share - When user "Brian" shares file "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing subfolder of already shared folder, GET result is correct - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - | David | - | Emily | - And user "Alice" has created folder "/folder1" - And user "Alice" has shared folder "/folder1" with user "Brian" - And user "Alice" has shared folder "/folder1" with user "Carol" - And user "Alice" has created folder "/folder1/folder2" - And user "Alice" has shared folder "/folder1/folder2" with user "David" - And user "Alice" has shared folder "/folder1/folder2" with user "Emily" - When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the response should contain 4 entries - And folder "/folder1" should be included as path in the response - And folder "/folder1/folder2" should be included as path in the response - When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2" - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the response should contain 2 entries - And folder "/folder1" should not be included as path in the response - And folder "/folder1/folder2" should be included as path in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user shares a file with file name longer than 64 chars to another user - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" - When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user shares a file with file name longer than 64 chars to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" - When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user shares a folder with folder name longer than 64 chars to another user - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" - And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" - And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" - When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user shares a folder with folder name longer than 64 chars to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" - And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" - And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" - When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario: share with user when username contains capital letters - Given these users have been created without skeleton files: - | username | - | brian | - And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" - When user "Alice" shares file "/randomfile.txt" with user "BRIAN" using the sharing API - 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 "Alice" sharing with user "BRIAN" should include - | share_with | brian | - | file_target | /randomfile.txt | - | path | /randomfile.txt | - | permissions | share,read,update | - | uid_owner | %username% | - And user "brian" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "brian" should be "Random data" - - @skipOnLDAP - Scenario: creating a new share with user of a group when username contains capital letters - Given these users have been created without skeleton files: - | username | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" - When user "Alice" shares file "randomfile.txt" with group "grp1" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /randomfile.txt | - And the content of file "randomfile.txt" for user "Brian" should be "Random data" - - - Scenario Outline: Share of folder to a group with emoji in the name - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And group "ЁЯША ЁЯШБ" has been created - And user "Brian" has been added to group "ЁЯША ЁЯШБ" - And user "Carol" has been added to group "ЁЯША ЁЯШБ" - And user "Alice" has created folder "/PARENT" - And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" - When user "Alice" shares folder "/PARENT" with group "ЁЯША ЁЯШБ" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - And user "Carol" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP - Scenario Outline: share with a group and then add a user to that group - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And these groups have been created: - | groupname | - | grp1 | - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "some content" to "lorem.txt" - And user "Alice" has shared file "lorem.txt" with group "grp1" - When the administrator adds user "Carol" to group "grp1" using the provisioning API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "lorem.txt" for user "Brian" should be "some content" - And the content of file "lorem.txt" for user "Carol" should be "some content" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnLDAP - # deleting an LDAP group is not relevant or possible using the provisioning API - Scenario Outline: shares shared to deleted group should not be available - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with group "grp1" - When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_with | grp1 | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | uid_owner | %username% | - And as "Brian" file "/textfile0.txt" should exist - And as "Carol" file "/textfile0.txt" should exist - When the administrator deletes group "grp1" using the provisioning API - And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" - Then the OCS status code should be "" - And the HTTP status code should be "200" - And file "/textfile0.txt" should not be included as path in the response - And as "Brian" file "/textfile0.txt" should not exist - And as "Carol" file "/textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnFilesClassifier @issue-files-classifier-291 - Scenario: Share a file by multiple channels and download from sub-folder and direct file share - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/common" - And user "Alice" has created folder "/common/sub" - And user "Alice" has shared folder "common" with group "grp1" - And user "Brian" has uploaded file with content "ownCloud" to "/textfile0.txt" - And user "Brian" has shared file "textfile0.txt" with user "Carol" - And user "Brian" has moved file "/textfile0.txt" to "/common/textfile0.txt" - And user "Brian" has moved file "/common/textfile0.txt" to "/common/sub/textfile0.txt" - When user "Carol" 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 "/common/sub/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line - And the content of file "/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line - And user "Carol" should see the following elements - | /common/sub/textfile0.txt | - | /textfile0.txt | - - - Scenario Outline: sharing back to resharer is not allowed - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "userZeroFolder" - And user "Alice" has shared folder "userZeroFolder" with user "Brian" - And user "Brian" has created folder "userZeroFolder/userOneFolder" - And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" - When user "Carol" shares folder "userOneFolder" with user "Brian" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Brian" folder "userOneFolder" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: sharing back to original sharer is not allowed - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "userZeroFolder" - And user "Alice" has shared folder "userZeroFolder" with user "Brian" - And user "Brian" has created folder "userZeroFolder/userOneFolder" - And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" - When user "Carol" shares folder "userOneFolder" with user "Alice" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Alice" folder "userOneFolder" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @issue-enterprise-3896 - Scenario Outline: sharing a subfolder to a user that already received parent folder share is not allowed - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - | David | - And user "Alice" has created folder "userZeroFolder" - And user "Alice" has shared folder "userZeroFolder" with user "Brian" - And user "Alice" has shared folder "userZeroFolder" with user "Carol" - And user "Brian" has created folder "userZeroFolder/userOneFolder" - And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "David" with permissions "read, share" - When user "David" shares folder "userOneFolder" with user "Carol" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "userOneFolder" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: shares to a deleted user should not be listed as shares for the sharer - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Alice" has shared file "textfile0.txt" with user "Carol" - And the administrator has deleted user "Brian" using the provisioning API - When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be included in the response - But user "Brian" should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @issue-ocis-719 - Scenario Outline: Creating a share of a renamed file when another share exists - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/Folder1" - And user "Alice" has created folder "/Folder2" - And user "Alice" has shared folder "/Folder1" with user "Brian" - And user "Alice" has moved folder "/Folder2" to "/renamedFolder2" - When user "Alice" shares folder "/renamedFolder2" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /renamedFolder2 | - | path | /renamedFolder2 | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | user | - And as "Brian" folder "/renamedFolder2" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature deleted file mode 100644 index ffdc7eb861..0000000000 --- a/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature +++ /dev/null @@ -1,182 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: Delete all group shares - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has shared file "fileToShare.txt" with group "grp1" - When user "Alice" deletes the last share using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should not see the share id of the last share - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: delete a share - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has shared file "fileToShare.txt" with user "Brian" - When user "Alice" deletes the last share using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share id should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario: orphaned shares - Given using OCS API version "1" - And user "Alice" has created folder "/common" - And user "Alice" has created folder "/common/sub" - And user "Alice" has shared folder "/common/sub" with user "Brian" - When user "Alice" deletes folder "/common" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" folder "/sub" should not exist - - @smokeTest @files_trashbin-app-required - Scenario: deleting a file out of a share as recipient creates a backup for the owner - Given using OCS API version "1" - And user "Alice" has created folder "/shared" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has moved file "/fileToShare.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" file "/shared/shared_file.txt" should not exist - And as "Alice" file "/shared/shared_file.txt" should not exist - And as "Alice" file "/shared_file.txt" should exist in the trashbin - And as "Brian" file "/shared_file.txt" should exist in the trashbin - - @files_trashbin-app-required - Scenario: deleting a folder out of a share as recipient creates a backup for the owner - Given using OCS API version "1" - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/sub" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/sub/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - When user "Brian" deletes folder "/shared/sub" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" folder "/shared/sub" should not exist - And as "Alice" folder "/shared/sub" should not exist - And as "Alice" folder "/sub" should exist in the trashbin - And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin - And as "Brian" folder "/sub" should exist in the trashbin - And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin - - @smokeTest - Scenario: unshare from self - And group "grp1" has been created - And these users have been created with default attributes and without skeleton files: - | username | - | Carol | - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Carol" has created folder "/PARENT" - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" - And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1" - And user "Carol" has stored etag of element "/PARENT" - And user "Brian" has stored etag of element "/" - When user "Brian" unshares file "parent.txt" using the WebDAV API - Then the HTTP status code should be "204" - And the etag of element "/" of user "Brian" should have changed - And the etag of element "/PARENT" of user "Carol" should not have changed - - - Scenario: sharee of a read-only share folder tries to delete the shared folder - Given using OCS API version "1" - And user "Alice" has created folder "/shared" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/shared_file.txt" - And user "Alice" has shared folder "shared" with user "Brian" with permissions "read" - When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Brian" file "/shared/shared_file.txt" should exist - - - Scenario: sharee of a upload-only shared folder tries to delete a file in the shared folder - Given using OCS API version "1" - And user "Alice" has created folder "/shared" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/shared_file.txt" - And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" - When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/shared/shared_file.txt" should exist - - - Scenario: sharee of an upload-only shared folder tries to delete their file in the folder - Given using OCS API version "1" - And user "Alice" has created folder "/shared" - And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "shared/textfile.txt" - When user "Brian" deletes file "/shared/textfile.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/shared/textfile.txt" should exist - - - Scenario Outline: A Group share recipient tries to delete the share - Given using OCS API version "" - And group "grp1" has been created - And these users have been created with default attributes and without skeleton files: - | username | - | Carol | - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" - And user "Alice" has shared entry "" with group "grp1" - When user "Brian" deletes the last share of user "Alice" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Alice" entry "" should exist - And as "Brian" entry "" should exist - And as "Carol" entry "" should exist - Examples: - | entry_to_share | ocs_api_version | http_status_code | received_entry | - | /PARENT/parent.txt | 1 | 200 | parent.txt | - | /PARENT/parent.txt | 2 | 404 | parent.txt | - | /PARENT | 1 | 200 | PARENT | - | /PARENT | 2 | 404 | PARENT | - - - Scenario Outline: An individual share recipient tries to delete the share - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" - And user "Alice" has shared entry "" with user "Brian" - When user "Brian" deletes the last share of user "Alice" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Alice" entry "" should exist - And as "Brian" entry "" should exist - Examples: - | entry_to_share | ocs_api_version | http_status_code | received_entry | - | /PARENT/parent.txt | 1 | 200 | parent.txt | - | /PARENT/parent.txt | 2 | 404 | parent.txt | - | /PARENT | 1 | 200 | PARENT | - | /PARENT | 2 | 404 | PARENT | - - - Scenario Outline: delete a share with wrong authentication - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has shared file "fileToShare.txt" with user "Brian" - When user "Brian" tries to delete the last share of user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 404 | 200 | - | 2 | 404 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature deleted file mode 100644 index ca5ef40231..0000000000 --- a/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature +++ /dev/null @@ -1,159 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: Exclude groups from receiving shares - As an admin - I want to exclude groups from receiving shares - So that users do not mistakenly share with groups they should not e.g. huge meta groups - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - | David | - And group "grp1" has been created - And group "grp2" has been created - And user "Brian" has been added to group "grp1" - And user "David" has been added to group "grp2" - - - Scenario Outline: user cannot share with a group that is excluded from receiving shares but can share with other groups - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" file "/fileToShare.txt" should not exist - When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" folder "/PARENT" should not exist - When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API - And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API - Then as "David" file "/fileToShare.txt" should exist - And as "David" folder "/PARENT" should exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: exclude multiple groups from receiving shares stops the user to share with any of them - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And group "grp3" has been created - And user "Brian" has been added to group "grp3" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And the administrator adds group "grp2" to the exclude groups from receiving shares list using the occ command - And the administrator adds group "grp3" to the exclude groups from receiving shares list using the occ command - And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" file "/fileToShare.txt" should not exist - When user "Alice" shares folder "PARENT" with group "grp2" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" folder "/PARENT" should not exist - When user "Alice" shares folder "PARENT/CHILD" with group "grp3" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" folder "/CHILD" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: user cannot reshare a received share with a group that is excluded from receiving shares but can share with other groups - Given using OCS API version "" - And user "Carol" has created folder "PARENT" - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Carol" has shared file "fileToShare.txt" with user "Alice" - And user "Carol" has shared folder "PARENT" with user "Alice" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" file "/fileToShare.txt" should not exist - When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API - Then the OCS status code should be "403" - And the HTTP status code should be "" - And the OCS status message should be "The group is blacklisted for sharing" - And as "Brian" folder "/PARENT" should not exist - When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API - And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API - Then as "David" file "/fileToShare.txt" should exist - And as "David" folder "/PARENT" should exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares still works - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "/fileToShare.txt" should exist - And as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares using an other group works - Given using OCS API version "" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And group "grp3" has been created - And user "Brian" has been added to group "grp3" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And user "Alice" shares file "fileToShare.txt" with group "grp3" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Alice" shares folder "PARENT" with group "grp3" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "/fileToShare.txt" should exist - And as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: a user that is part of a group that is excluded from receiving shares still can initiate shares - Given using OCS API version "" - And user "Brian" has created folder "PARENT" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command - And user "Brian" shares file "fileToShare.txt" with user "Carol" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Brian" shares folder "PARENT" with user "Carol" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" file "/fileToShare.txt" should exist - And as "Carol" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature deleted file mode 100644 index e8322eaf8b..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature +++ /dev/null @@ -1,960 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: accept/decline shares coming from internal users - As a user - I want to have control of which received shares I accept - So that I can keep my file system clean - - Background: - Given using OCS API version "1" - And using new DAV path - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "FOLDER" - And user "Brian" has created folder "PARENT" - And user "Brian" has created folder "FOLDER" - And user "Carol" has created folder "PARENT" - And user "Carol" has created folder "FOLDER" - And user "Alice" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" - And user "Brian" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" - And user "Carol" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" - And user "Alice" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" - And user "Brian" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" - And user "Carol" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" - - @smokeTest - Scenario Outline: share a file & folder with another internal user with different permissions when auto accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has created folder "PARENT/CHILD" - And user "Brian" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" - And user "Brian" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" - When user "Alice" creates a share using the sharing API with settings - | path | PARENT | - | shareType | user | - | shareWith | Brian | - | permissions | | - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - And the content of file "/PARENT (2)/CHILD/child.txt" for user "Brian" should be "ownCloud test text file child" - And the content of file "/textfile0 (2).txt" for user "Brian" should be "ownCloud text file 0" - Examples: - | permissions | - | read | - | change | - | all | - - - Scenario Outline: share a file & folder with another internal user when auto accept is enabled and there is a default folder for received shares - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And the administrator has set the default folder for received shares to "" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | // | - | //parent.txt | - | /textfile0.txt | - | / | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | // | - | / | - Examples: - | share_folder | top_folder | received_parent_name | received_textfile_name | - | | | PARENT (2) | textfile0 (2).txt | - | / | | PARENT (2) | textfile0 (2).txt | - | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | - - - Scenario Outline: share a file & folder with internal group with different permissions when auto accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has created folder "PARENT/CHILD" - And user "Brian" has created folder "PARENT/CHILD" - And user "Carol" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" - And user "Brian" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" - And user "Carol" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" - When user "Alice" creates a share using the sharing API with settings - | path | PARENT | - | shareType | group | - | shareWith | grp1 | - | permissions | | - And user "Alice" shares file "/textfile0.txt" with group "grp1" 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 user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - And user "Carol" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Carol" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - And the content of file "/PARENT (2)/CHILD/child.txt" for user "Carol" should be "ownCloud test text file child" - And the content of file "/textfile0 (2).txt" for user "Carol" should be "ownCloud text file 0" - Examples: - | permissions | - | read | - | change | - | all | - - @smokeTest - Scenario Outline: decline a share that has been auto-accepted - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" declines share "/PARENT (2)" offered by user "Alice" using the sharing API - And user "Brian" declines share "/textfile0 (2).txt" offered by user "Alice" 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 user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | | - | | - Examples: - | declined_share_path_1 | declined_share_path_2 | - | /PARENT (2)/ | /textfile0 (2).txt | - - - Scenario Outline: accept a share that has been declined before - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - And user "Brian" has declined share "/PARENT (2)" offered by user "Alice" - And user "Brian" has declined share "/textfile0 (2).txt" offered by user "Alice" - When user "Brian" accepts share "" offered by user "Alice" using the sharing API - And user "Brian" accepts share "" offered by user "Alice" 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 user "Brian" should see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - Examples: - | pending_share_path_1 | pending_share_path_2 | - | /PARENT (2) | /textfile0 (2).txt | - - - Scenario Outline: unshare a share that has been auto-accepted - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" unshares folder "/PARENT (2)" using the WebDAV API - And user "Brian" unshares file "/textfile0 (2).txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | | - | | - Examples: - | declined_share_path_1 | declined_share_path_2 | - | /PARENT (2)/ | /textfile0 (2).txt | - - - Scenario Outline: unshare a share that was shared with a group and auto-accepted - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with group "grp1" - And user "Alice" has shared file "/textfile0.txt" with group "grp1" - When user "Brian" unshares folder "/PARENT (2)" using the WebDAV API - And user "Brian" unshares file "/textfile0 (2).txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | | - | | - But user "Carol" should see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Carol" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - Examples: - | declined_share_path_1 | declined_share_path_2 | - | /PARENT (2)/ | /textfile0 (2).txt | - - - Scenario Outline: rename accepted share, decline it - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" moves folder "/PARENT (2)" to "/PARENT-renamed" using the WebDAV API - And user "Brian" declines share "/PARENT-renamed" offered by user "Alice" using the sharing API - Then the HTTP status code of responses on each endpoint should be "201, 200" respectively - #OCS status code is checked only for Sharing API request - And the OCS status code should be "100" - And user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT-renamed/ | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | | - Examples: - | declined_share_path | - | /PARENT-renamed/ | - - - Scenario Outline: rename accepted share, decline it then accept again, name stays - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Brian" has moved folder "/PARENT (2)" to "/PARENT-renamed" - When user "Brian" declines share "/PARENT-renamed" offered by user "Alice" using the sharing API - And user "Brian" accepts share "" offered by user "Alice" 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 user "Brian" should see the following elements - | /PARENT/ | - | /PARENT-renamed/ | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT-renamed/ | - Examples: - | declined_share_path | - | /PARENT-renamed | - - - Scenario Outline: move accepted share, decline it, accept again - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has moved folder "/shared" to "/PARENT/shared" - When user "Brian" declines share "/PARENT/shared" offered by user "Alice" using the sharing API - And user "Brian" accepts share "" offered by user "Alice" 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 user "Brian" should not see the following elements - | /shared/ | - But user "Brian" should see the following elements - | /PARENT/shared/ | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT/shared/ | - Examples: - | declined_share_path | - | /PARENT/shared | - - - Scenario Outline: move accepted share, decline it, delete parent folder, accept again - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has moved folder "/shared" to "/PARENT/shared" - When user "Brian" declines share "/PARENT/shared" offered by user "Alice" using the sharing API - And user "Brian" deletes folder "/PARENT" using the WebDAV API - And user "Brian" accepts share "" offered by user "Alice" using the sharing API - Then the HTTP status code of responses on each endpoint should be "200, 204, 200" respectively - #OCS status code is checked only for Sharing API request - And the OCS status code of responses on all endpoints should be "100" - And user "Brian" should not see the following elements - | /PARENT/ | - But user "Brian" should see the following elements - | /shared/ | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /shared/ | - Examples: - | declined_share_path | - | /PARENT/shared | - - - Scenario: receive two shares with identical names from different users - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/Alice" - And user "Brian" has created folder "/shared" - And user "Brian" has created folder "/shared/Brian" - When user "Alice" shares folder "/shared" with user "Carol" using the sharing API - And user "Brian" shares folder "/shared" with user "Carol" 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 user "Carol" should see the following elements - | /shared/Alice/ | - | /shared (2)/Brian/ | - And the sharing API should report to user "Carol" that these shares are in the accepted state - | path | - | /shared/ | - | /shared (2)/ | - - @smokeTest - Scenario: share a file & folder with another internal group when auto accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And user "Alice" shares file "/textfile0.txt" with group "grp1" 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 user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /textfile0.txt | - But user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the pending state - | path | - | /PARENT/ | - | /textfile0.txt | - And user "Carol" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /textfile0.txt | - But user "Carol" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Carol" that these shares are in the pending state - | path | - | /PARENT/ | - | /textfile0.txt | - - - Scenario: share a file & folder with another internal user when auto accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /textfile0.txt | - But user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the pending state - | path | - | /PARENT/ | - | /textfile0.txt | - - @smokeTest - Scenario: accept a pending share - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 the fields of the last response to user "Alice" sharing with user "Brian" should include - | id | A_STRING | - | share_type | user | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | share,read,update | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | state | 0 | - | path | /textfile0 (2).txt | - | item_type | file | - | mimetype | text/plain | - | storage_id | shared::/textfile0 (2).txt | - | storage | A_STRING | - | item_source | A_STRING | - | file_source | A_STRING | - | file_target | /textfile0 (2).txt | - | share_with | %username% | - | share_with_displayname | %displayname% | - | mail_send | 0 | - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /textfile0.txt | - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - - - Scenario Outline: accept a pending share when there is a default folder for received shares - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And the administrator has set the default folder for received shares to "" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 the fields of the last response to user "Alice" sharing with user "Brian" should include - | id | A_STRING | - | share_type | user | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | share,read,update | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | state | 0 | - | path | / | - | item_type | file | - | mimetype | text/plain | - | storage_id | shared::/ | - | storage | A_STRING | - | item_source | A_STRING | - | file_source | A_STRING | - | file_target | / | - | share_with | %username% | - | share_with_displayname | %displayname% | - | mail_send | 0 | - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | // | - | //parent.txt | - | /textfile0.txt | - | / | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | // | - | / | - Examples: - | share_folder | top_folder | received_parent_name | received_textfile_name | - | | | PARENT (2) | textfile0 (2).txt | - | / | | PARENT (2) | textfile0 (2).txt | - | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | - - - Scenario: accept an accepted share - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - When user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/shared" offered by user "Alice" 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 user "Brian" should see the following elements - | /shared/ | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /shared/ | - - @smokeTest - Scenario: declines a pending share - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" declines share "/PARENT" offered by user "Alice" using the sharing API - And user "Brian" declines share "/textfile0.txt" offered by user "Alice" 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 user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /textfile0.txt | - But user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | /PARENT/ | - | /textfile0.txt | - - @smokeTest - Scenario Outline: decline an accepted share - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - When user "Brian" declines share "/PARENT (2)" offered by user "Alice" using the sharing API - And user "Brian" declines share "/textfile0 (2).txt" offered by user "Alice" 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 user "Brian" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | | - | | - Examples: - | declined_share_path_1 | declined_share_path_2 | - | /PARENT (2)/ | /textfile0 (2).txt | - - - Scenario: deleting shares in pending state - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Alice" deletes folder "/PARENT" using the WebDAV API - And user "Alice" deletes file "/textfile0.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And the sharing API should report that no shares are shared with user "Brian" - - - Scenario: only one user in a group accepts a share - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with group "grp1" - And user "Alice" has shared file "/textfile0.txt" with group "grp1" - When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 user "Carol" should not see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Carol" that these shares are in the pending state - | path | - | /PARENT/ | - | /textfile0.txt | - But user "Brian" should see the following elements - | /PARENT (2)/ | - | /PARENT (2)/parent.txt | - | /textfile0 (2).txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /PARENT (2)/ | - | /textfile0 (2).txt | - - - Scenario: receive two shares with identical names from different users, accept one by one - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/Alice" - And user "Brian" has created folder "/shared" - And user "Brian" has created folder "/shared/Brian" - And user "Alice" has shared folder "/shared" with user "Carol" - And user "Brian" has shared folder "/shared" with user "Carol" - When user "Carol" accepts share "/shared" offered by user "Brian" using the sharing API - And user "Carol" accepts share "/shared" offered by user "Alice" 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 user "Carol" should see the following elements - | /shared/Brian/ | - | /shared (2)/Alice/ | - And the sharing API should report to user "Carol" that these shares are in the accepted state - | path | - | /shared/ | - | /shared (2)/ | - - - Scenario: share with a group that you are part of yourself - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And the sharing API should report to user "Brian" that these shares are in the pending state - | path | - | /PARENT/ | - And the sharing API should report that no shares are shared with user "Alice" - - - Scenario Outline: user accepts file that was initially accepted from another user and then declined - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has uploaded file with content "First file" to "/testfile.txt" - And user "Brian" has uploaded file with content "Second file" to "/testfile.txt" - And user "Carol" has uploaded file with content "Third file" to "/testfile.txt" - And user "Alice" has shared file "/testfile.txt" with user "Carol" - And user "Carol" has accepted share "/testfile.txt" offered by user "Alice" - When user "Carol" declines share "/testfile (2).txt" offered by user "Alice" using the sharing API - And user "Brian" shares file "/testfile.txt" with user "Carol" using the sharing API - And user "Carol" accepts share "/testfile.txt" offered by user "Brian" using the sharing API - And user "Carol" accepts share "" offered by user "Alice" 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 the sharing API should report to user "Carol" that these shares are in the accepted state - | path | - | /testfile (2).txt | - | /testfile (2) (2).txt | - And the content of file "/testfile.txt" for user "Carol" should be "Third file" - And the content of file "/testfile (2).txt" for user "Carol" should be "Second file" - And the content of file "/testfile (2) (2).txt" for user "Carol" should be "First file" - Examples: - | accepted_share_path | - | /testfile (2).txt | - - - Scenario Outline: user accepts shares received from multiple users with the same name when auto-accept share is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "David" has been created with default attributes and without skeleton files - And user "David" has created folder "/PARENT" - And user "Brian" has shared folder "/PARENT" with user "Alice" - And user "Carol" has shared folder "/PARENT" with user "Alice" - When user "Alice" accepts share "/PARENT" offered by user "Brian" using the sharing API - And user "Alice" declines share "/PARENT (2)" offered by user "Brian" using the sharing API - And user "Alice" accepts share "/PARENT" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" offered by user "Brian" using the sharing API - And user "Alice" declines share "/PARENT (2)" offered by user "Carol" using the sharing API - And user "Alice" declines share "/PARENT (2) (2)" offered by user "Brian" using the sharing API - And user "David" shares folder "/PARENT" with user "Alice" using the sharing API - And user "Alice" accepts share "/PARENT" offered by user "David" using the sharing API - And user "Alice" accepts share "" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" 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" - And the sharing API should report to user "Alice" that these shares are in the accepted state - | path | uid_owner | - | /PARENT (2)/ | David | - | /PARENT (2) (2)/ | Carol | - | /PARENT (2) (2) (2)/ | Brian | - Examples: - | accepted_share_path_1 | accepted_share_path_2 | - | /PARENT (2) | /PARENT (2) (2) | - - - Scenario: user shares folder with matching folder-name for both user involved in sharing - Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" - And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares folder "/FOLDER" with 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" - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (2)/abc.txt | - | /FOLDER (2)/ | - | /FOLDER (2)/abc.txt | - And user "Brian" should not see the following elements - | /FOLDER/abc.txt | - | /PARENT/abc.txt | - And the content of file "/PARENT (2)/abc.txt" for user "Brian" should be "uploaded content" - And the content of file "/FOLDER (2)/abc.txt" for user "Brian" should be "uploaded content" - - - Scenario: user shares folder in a group with matching folder-name for every users involved - Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" - And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And user "Alice" shares folder "/FOLDER" with group "grp1" 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 user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /FOLDER (2)/ | - | /PARENT (2)/abc.txt | - | /FOLDER (2)/abc.txt | - And user "Brian" should not see the following elements - | /FOLDER/abc.txt | - | /PARENT/abc.txt | - And user "Carol" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | /PARENT (2)/ | - | /FOLDER (2)/ | - | /PARENT (2)/abc.txt | - | /FOLDER (2)/abc.txt | - And user "Carol" should not see the following elements - | /FOLDER/abc.txt | - | /PARENT/abc.txt | - And the content of file "/PARENT (2)/abc.txt" for user "Brian" should be "uploaded content" - And the content of file "/FOLDER (2)/abc.txt" for user "Brian" should be "uploaded content" - And the content of file "/PARENT (2)/abc.txt" for user "Carol" should be "uploaded content" - And the content of file "/FOLDER (2)/abc.txt" for user "Carol" should be "uploaded content" - - - Scenario: user shares files in a group with matching file-names for every users involved in sharing - Given user "Alice" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" - And user "Brian" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" - And user "Carol" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" - When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API - And user "Alice" shares file "/textfile1.txt" with group "grp1" 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 user "Brian" should see the following elements - | /textfile0.txt | - | /textfile1.txt | - | /textfile0 (2).txt | - | /textfile1 (2).txt | - And user "Carol" should see the following elements - | /textfile0.txt | - | /textfile1.txt | - | /textfile0 (2).txt | - | /textfile1 (2).txt | - - - Scenario: user shares resource with matching resource-name with another user when auto accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should see the following elements - | /PARENT/ | - | /textfile0.txt | - But user "Brian" should not see the following elements - | /textfile0 (2).txt | - | /PARENT (2)/ | - When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/PARENT" offered by user "Alice" 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 user "Brian" should see the following elements - | /PARENT/ | - | /textfile0.txt | - | /PARENT (2)/ | - | /textfile0 (2).txt | - - - Scenario: user shares file in a group with matching filename when auto accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /textfile0.txt | - But user "Brian" should not see the following elements - | /textfile0 (2).txt | - And user "Carol" should see the following elements - | /textfile0.txt | - But user "Carol" should not see the following elements - | /textfile0 (2).txt | - When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API - And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" 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 user "Brian" should see the following elements - | /textfile0.txt | - | /textfile0 (2).txt | - And user "Carol" should see the following elements - | /textfile0.txt | - | /textfile0 (2).txt | - - @skipOnLDAP - Scenario: user shares folder with matching folder name a user before that user has logged in - Given these users have been created with small skeleton files but not initialized: - | username | - | David | - And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" - When user "Alice" shares folder "/PARENT" with user "David" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And user "David" should see the following elements - | /PARENT/ | - | /PARENT/abc.txt | - | /FOLDER/ | - | /textfile0.txt | - | /textfile1.txt | - | /textfile2.txt | - | /textfile3.txt | - And user "David" should not see the following elements - | /PARENT (2)/ | - And the content of file "/PARENT/abc.txt" for user "David" should be "uploaded content" - - @issue-ocis-765 - Scenario: shares exist after restoring already shared file to a previous version - Given user "Alice" has uploaded file with content "Test Content." to "/toShareFile.txt" - And user "Alice" has uploaded file with content "Content Test Updated." to "/toShareFile.txt" - And user "Alice" has shared file "/toShareFile.txt" with user "Brian" - When user "Alice" restores version index "1" of file "/toShareFile.txt" using the WebDAV API - And the HTTP status code should be "204" - And the content of file "/toShareFile.txt" for user "Alice" should be "Test Content." - And the content of file "/toShareFile.txt" for user "Brian" should be "Test Content." - - - Scenario: a user receives multiple group shares for matching file and folder name - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And group "grp2" has been created - And user "Alice" has been added to group "grp2" - And user "Brian" has been added to group "grp2" - And user "Alice" has created folder "/PaRent" - And user "Alice" has uploaded the following files with content "subfile, from alice to grp2" - | path | - | /PARENT/parent.txt | - | /PaRent/parent.txt | - And user "Alice" has uploaded the following files with content "from alice to grp2" - | path | - | /PARENT.txt | - And user "Carol" has uploaded the following files with content "subfile, from carol to grp1" - | path | - | /PARENT/parent.txt | - And user "Carol" has uploaded the following files with content "from carol to grp1" - | path | - | /PARENT.txt | - | /parent.txt | - When user "Alice" shares the following entries with group "grp2" using the sharing API - | path | - | /PARENT | - | /PaRent | - | /PARENT.txt | - And user "Carol" shares the following entries with group "grp2" using the sharing API - | path | - | /PARENT | - | /PARENT.txt | - | /parent.txt | - And user "Brian" accepts the following shares offered by user "Alice" using the sharing API - | path | - | /PARENT | - | /PaRent | - | /PARENT.txt | - And user "Brian" accepts the following shares offered by user "Carol" using the sharing API - | path | - | /PARENT | - | /PARENT.txt | - | /parent.txt | - 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 user "Brian" should see the following elements - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (3)/ | - | /PaRent/ | - | /PARENT.txt | - | /PARENT (2).txt | - | /parent.txt | - And the content of file "/PARENT (2)/parent.txt" for user "Brian" should be "subfile, from alice to grp2" - And the content of file "/PARENT (3)/parent.txt" for user "Brian" should be "subfile, from carol to grp1" - And the content of file "/PARENT.txt" for user "Brian" should be "from alice to grp2" - And the content of file "/PARENT (2).txt" for user "Brian" should be "from carol to grp1" - And the content of file "/parent.txt" for user "Brian" should be "from carol to grp1" - - - Scenario: a group receives multiple shares from non-member for matching file and folder name - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Brian" has been removed from group "grp1" - And user "Alice" has created folder "/PaRent" - And user "Alice" has uploaded the following files with content "subfile, from alice to grp1" - | path | - | /PARENT/parent.txt | - | /PaRent/parent.txt | - And user "Alice" has uploaded the following files with content "from alice to grp1" - | path | - | /PARENT.txt | - And user "Brian" has uploaded the following files with content "subfile, from brian to grp1" - | path | - | /PARENT/parent.txt | - And user "Brian" has uploaded the following files with content "from brian to grp1" - | path | - | /PARENT.txt | - | /parent.txt | - When user "Alice" shares the following entries with group "grp1" using the sharing API - | path | - | /PARENT | - | /PaRent | - | /PARENT.txt | - And user "Brian" shares the following entries with group "grp1" using the sharing API - | path | - | /PARENT | - | /PARENT.txt | - | /parent.txt | - And user "Carol" accepts the following shares offered by user "Alice" using the sharing API - | path | - | /PARENT | - | /PaRent | - | /PARENT.txt | - And user "Carol" accepts the following shares offered by user "Brian" using the sharing API - | path | - | /PARENT | - | /PARENT.txt | - | /parent.txt | - 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 user "Carol" should see the following elements - | /PARENT/ | - | /PARENT (2)/ | - | /PARENT (3)/ | - | /PaRent/ | - | /PARENT.txt | - | /PARENT (2).txt | - | /parent.txt | - And the content of file "/PARENT (2)/parent.txt" for user "Carol" should be "subfile, from alice to grp1" - And the content of file "/PARENT (3)/parent.txt" for user "Carol" should be "subfile, from brian to grp1" - And the content of file "/PARENT.txt" for user "Carol" should be "from alice to grp1" - And the content of file "/PARENT (2).txt" for user "Carol" should be "from brian to grp1" - - - Scenario: user receives a share and uploads a file with the identical name - Given user "Alice" has uploaded file with content "from alice" to "/message.txt" - And user "Alice" has shared file "/message.txt" with user "Carol" - And user "Carol" has accepted share "/message.txt" offered by user "Alice" - When user "Carol" declines share "/message.txt" offered by user "Alice" using the sharing API - And user "Carol" uploads file with content "carol file" to "/message.txt" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "200, 201" respectively - And the OCS status code of responses on all endpoints should be "100" - And user "Carol" should see the following elements - | /message.txt | - And the content of file "/message.txt" for user "Carol" should be "carol file" - When user "Carol" accepts share "/message.txt" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "100" - And user "Carol" should see the following elements - | /message.txt | - | /message (2).txt | - And the content of file "/message (2).txt" for user "Carol" should be "from alice" - - - Scenario: user receives a share and creates a folder with the identical name - Given user "Alice" has created folder "/PaRent" - And user "Alice" has uploaded file with content "from alice" to "/PaRent/message.txt" - And user "Alice" has shared folder "/PaRent" with user "Carol" - And user "Carol" has accepted share "/PaRent" offered by user "Alice" - When user "Carol" declines share "/PaRent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "100" - When user "Carol" creates folder "/PaRent" using the WebDAV API - And user "Carol" uploads file with content "carol file" to "/PaRent/message.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - And user "Carol" should see the following elements - | /PaRent/ | - And the content of file "/PaRent/message.txt" for user "Carol" should be "carol file" - When user "Carol" accepts share "/PaRent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "100" - And user "Carol" should see the following elements - | /PaRent/ | - | /PaRent (2)/ | - And the content of file "/PaRent (2)/message.txt" for user "Carol" should be "from alice" diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature b/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature deleted file mode 100644 index f851abb62d..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature +++ /dev/null @@ -1,175 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - As an admin - I want to be able to disable sharing functionality - So that ownCloud users cannot share file or folder - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario Outline: user tries to share a file with another user when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to share file "fileToShare.txt" with user "Brian" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: user tries to share a folder with another user when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to share folder "/FOLDER" with user "Brian" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: user tries to share a file with group when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: user tries to share a folder with group when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to share folder "/FOLDER" with group "grp1" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: user tries to create public link share of a file when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to create a public link share of file "fileToShare.txt" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @smokeTest - Scenario Outline: user tries to create public link share of a folder when the sharing api has been disabled - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - When parameter "shareapi_enabled" of app "core" has been set to "no" - Then user "Alice" should not be able to create a public link share of folder "/FOLDER" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @smokeTest - Scenario Outline: user tries to share a file with user who is not in their group when sharing outside the group has been restricted - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" - Then user "Brian" should not be able to share file "fileToShare.txt" with user "Alice" using the sharing API - And the OCS status code should be "403" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 403 | - - - Scenario Outline: user shares a file with user who is in their group when sharing outside the group has been restricted - Given using OCS API version "" - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" - Then user "Carol" should be able to share file "fileToShare.txt" with user "Brian" using the sharing API - And the OCS status code should be "" - And the HTTP status code should be "200" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user shares a file with the group they are not member of when sharing outside the group has been restricted - Given using OCS API version "" - And group "grp2" has been created - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp2" - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" - Then user "Carol" should be able to share file "fileToShare.txt" with group "grp1" using the sharing API - And the OCS status code should be "" - And the HTTP status code should be "200" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: user who is not a member of a group tries to share a file in the group when group sharing has been disabled - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - Then user "Alice" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: user who is a member of a group tries to share a file in the group when group sharing has been disabled - Given using OCS API version "" - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - When parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - Then user "Carol" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API - And the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature deleted file mode 100644 index 466572d8ba..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature +++ /dev/null @@ -1,126 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - - @smokeTest - Scenario: Merging shares for recipient when shared from outside with group and member - Given user "Alice" has created folder "/merge-test-outside" - When user "Alice" shares folder "/merge-test-outside" with group "grp1" using the sharing API - And user "Alice" shares folder "/merge-test-outside" with 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" - And as "Brian" folder "/merge-test-outside" should exist - And as "Brian" folder "/merge-test-outside (2)" should not exist - - - Scenario: Merging shares for recipient when shared from outside with group and member with different permissions - Given user "Alice" has created folder "/merge-test-outside-perms" - When user "Alice" shares folder "/merge-test-outside-perms" with group "grp1" with permissions "read" using the sharing API - And user "Alice" shares folder "/merge-test-outside-perms" with user "Brian" with permissions "all" 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 user "Brian" folder "/merge-test-outside-perms" should contain a property "oc:permissions" with value "SRDNVCK" - And as "Brian" folder "/merge-test-outside-perms (2)" should not exist - - - Scenario: Merging shares for recipient when shared from outside with two groups - Given group "grp2" has been created - And user "Brian" has been added to group "grp2" - And user "Alice" has created folder "/merge-test-outside-twogroups" - When user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp1" using the sharing API - And user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp2" 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 "Brian" folder "/merge-test-outside-twogroups" should exist - And as "Brian" folder "/merge-test-outside-twogroups (2)" should not exist - - - Scenario: Merging shares for recipient when shared from outside with two groups with different permissions - Given group "grp2" has been created - And user "Brian" has been added to group "grp2" - And user "Alice" has created folder "/merge-test-outside-twogroups-perms" - When user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp1" with permissions "read" using the sharing API - And user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp2" with permissions "all" 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 user "Brian" folder "/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SRDNVCK" - And as "Brian" folder "/merge-test-outside-twogroups-perms (2)" should not exist - - - Scenario: Merging shares for recipient when shared from outside with two groups and member - Given group "grp2" has been created - And user "Brian" has been added to group "grp2" - And user "Alice" has created folder "/merge-test-outside-twogroups-member-perms" - When user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp1" with permissions "read" using the sharing API - And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp2" with permissions "all" using the sharing API - And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with user "Brian" with permissions "read" 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 user "Brian" folder "/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SRDNVCK" - And as "Brian" folder "/merge-test-outside-twogroups-member-perms (2)" should not exist - - - Scenario: Merging shares for recipient when shared from inside with group - Given user "Brian" has created folder "/merge-test-inside-group" - When user "Brian" shares folder "/merge-test-inside-group" with group "grp1" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "100" - And as "Brian" folder "/merge-test-inside-group" should exist - And as "Brian" folder "/merge-test-inside-group (2)" should not exist - - - Scenario: Merging shares for recipient when shared from inside with two groups - Given group "grp2" has been created - And user "Brian" has been added to group "grp2" - And user "Brian" has created folder "/merge-test-inside-twogroups" - When user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp1" using the sharing API - And user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp2" 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 "Brian" folder "/merge-test-inside-twogroups" should exist - And as "Brian" folder "/merge-test-inside-twogroups (2)" should not exist - And as "Brian" folder "/merge-test-inside-twogroups (3)" should not exist - - - Scenario: Merging shares for recipient when shared from inside with group with less permissions - Given group "grp2" has been created - And user "Brian" has been added to group "grp2" - And user "Brian" has created folder "/merge-test-inside-twogroups-perms" - When user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp1" using the sharing API - And user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp2" 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 user "Brian" folder "/merge-test-inside-twogroups-perms" should contain a property "oc:permissions" with value "RDNVCK" or with value "RMDNVCK" - And as "Brian" folder "/merge-test-inside-twogroups-perms (2)" should not exist - And as "Brian" folder "/merge-test-inside-twogroups-perms (3)" should not exist - - - Scenario: Merging shares for recipient when shared from outside with group then user and recipient renames in between - Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" - When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API - And user "Brian" moves folder "/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API - And user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API - Then the HTTP status code of responses on each endpoint should be "200, 201, 200" respectively - #OCS status code is checked only for Sharing API request - And the OCS status code of responses on all endpoints should be "100" - And as user "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should contain a property "oc:permissions" with value "SRDNVCK" - And as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare" should not exist - - - Scenario: Merging shares for recipient when shared from outside with user then group and recipient renames in between - Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" - When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API - And user "Brian" moves folder "/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API - And user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API - Then the HTTP status code of responses on each endpoint should be "200, 201, 200" respectively - And the OCS status code of responses on all endpoints should be "100" - And as user "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should contain a property "oc:permissions" with value "SRDNVCK" - And as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature deleted file mode 100644 index 444d14c8f1..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature +++ /dev/null @@ -1,103 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - - - Scenario: Keep usergroup shares (#22143) - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/TMP" - When user "Alice" shares folder "TMP" with group "grp1" using the sharing API - And user "Brian" creates folder "/myFOLDER" using the WebDAV API - And user "Brian" moves folder "/TMP" to "/myFOLDER/myTMP" using the WebDAV API - And the administrator deletes user "Carol" using the provisioning 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 user "Brian" should see the following elements - | /myFOLDER/myTMP/ | - - - Scenario: keep user shared file name same after one of recipient has renamed the file - Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" - And user "Alice" has shared file "/sharefile.txt" with user "Brian" - And user "Alice" has shared file "/sharefile.txt" with user "Carol" - When user "Carol" moves file "/sharefile.txt" to "/renamedsharefile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Carol" file "/renamedsharefile.txt" should exist - And as "Alice" file "/sharefile.txt" should exist - And as "Brian" file "/sharefile.txt" should exist - - - Scenario: keep user shared file directory same in respect to respective user if one of the recipient has moved the file - Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" - And user "Alice" has shared file "/sharefile.txt" with user "Brian" - And user "Alice" has shared file "/sharefile.txt" with user "Carol" - And user "Carol" has created folder "newfolder" - When user "Carol" moves file "/sharefile.txt" to "/newfolder/sharefile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Carol" file "/newfolder/sharefile.txt" should exist - And as "Alice" file "/sharefile.txt" should exist - And as "Brian" file "/sharefile.txt" should exist - - - Scenario Outline: move folder inside received folder with special characters - Given group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "" - And user "Alice" has created folder "" - And user "Brian" has created folder "" - And user "Carol" has created folder "" - When user "Alice" shares folder "" with user "Brian" using the sharing API - And user "Brian" moves folder "" to "/" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "200, 201" respectively - #OCS status code is checked only for Sharing API request - And the OCS status code of responses on all endpoints should be "100" - And as "Alice" folder "/" should exist - And as "Brian" folder "/" should exist - When user "Alice" shares folder "" with group "grp1" using the sharing API - And user "Carol" moves folder "" to "/" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "200, 201" respectively - And the OCS status code of responses on all endpoints should be "100" - And as "Alice" folder "/" should exist - And as "Carol" folder "/" should exist - Examples: - | sharer_folder | group_folder | receiver_folder | - | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | - | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | - - - Scenario: receiver renames a received share with share, read, change permissions - Given user "Alice" has created folder "folderToShare" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" - And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change" - When user "Brian" moves folder "folderToShare" to "myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/myFolder/renamedFile" should exist - And as "Alice" file "/folderToShare/renamedFile" should exist - But as "Alice" file "/folderToShare/fileInside" should not exist - - - Scenario: receiver tries to rename a received share with share, read permissions - Given user "Alice" has created folder "folderToShare" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" - And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read" - When user "Brian" moves folder "folderToShare" to "myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API - Then the HTTP status code should be "403" - And as "Brian" file "/myFolder/renamedFile" should not exist - But as "Brian" file "/myFolder/fileInside" should exist diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature deleted file mode 100644 index b06c544f72..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature +++ /dev/null @@ -1,64 +0,0 @@ -@api @local_storage @files_external-app-required @notToImplementOnOCIS -Feature: local-storage - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: receiver renames a received file share from local storage - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - And user "Alice" has shared file "/local_storage/filetoshare.txt" with user "Brian" - When user "Brian" moves file "/filetoshare.txt" to "/newFile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/newFile.txt" should exist - But as "Brian" file "/filetoshare.txt.txt" should not exist - And as "Alice" file "/local_storage/filetoshare.txt" should exist - But as "Alice" file "/local_storage/newFile.txt" should not exist - Examples: - | ocs_api_version | - | 1 | - | 2 | - - - Scenario Outline: receiver renames a received folder share from local storage - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - And user "Alice" has shared folder "/local_storage/foo" with user "Brian" - When user "Brian" moves folder "/foo" to "/newFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/newFolder" should exist - But as "Brian" folder "/foo" should not exist - And as "Alice" folder "/local_storage/foo" should exist - But as "Alice" folder "/local_storage/newFolder" should not exist - Examples: - | ocs_api_version | - | 1 | - | 2 | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: sub-folders,file inside a renamed received folder shared from local storage are accessible - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/foo/filetoshare.txt" - And user "Alice" has created folder "/local_storage/foo/folder1" - And user "Alice" has created folder "/local_storage/foo/folder2" - And user "Alice" has created folder "/local_storage/foo/folder2/subfolder" - And user "Alice" has shared folder "/local_storage/foo" with user "Brian" - When user "Brian" moves folder "/foo" to "/newFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/newFolder" should exist - And as "Brian" file "/newFolder/filetoshare.txt" should exist - And as "Brian" folder "/newFolder/folder1" should exist - And as "Brian" folder "/newFolder/folder2" should exist - And as "Brian" folder "/newFolder/folder2/subfolder" should exist - But as "Brian" folder "/foo" should not exist - And as "Alice" folder "/local_storage/foo" should exist - But as "Alice" folder "/local_storage/newFolder" should not exist - Examples: - | ocs_api_version | - | 1 | - | 2 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature deleted file mode 100644 index c3f3f48d10..0000000000 --- a/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature +++ /dev/null @@ -1,79 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: moving a share inside another share - As a user - I want to move a shared resource inside another shared resource - Because I need full flexibility when managing resources. - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has created folder "folderA" - And user "Alice" has created folder "folderB" - And user "Alice" has uploaded file with content "text A" to "/folderA/fileA.txt" - And user "Alice" has uploaded file with content "text B" to "/folderB/fileB.txt" - And user "Alice" has shared folder "folderA" with user "Brian" - And user "Alice" has shared folder "folderB" with user "Brian" - - - Scenario: share receiver cannot move a whole share inside another share - When user "Brian" moves folder "folderB" to "folderA/folderB" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" folder "/folderB" should exist - And as "Brian" folder "/folderB" should exist - And as "Alice" file "/folderB/fileB.txt" should exist - And as "Brian" file "/folderB/fileB.txt" should exist - - - Scenario: share owner moves a whole share inside another share - When user "Alice" moves folder "folderB" to "folderA/folderB" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" folder "/folderB" should not exist - And as "Alice" folder "/folderA/folderB" should exist - And as "Brian" folder "/folderB" should exist - And as "Alice" file "/folderA/folderB/fileB.txt" should exist - And as "Brian" file "/folderA/folderB/fileB.txt" should exist - And as "Brian" file "/folderB/fileB.txt" should exist - - - Scenario: share receiver moves a whole share inside a local folder - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/localFolder/folderB" should exist - And as "Brian" file "/localFolder/folderB/fileB.txt" should exist - And as "Brian" file "/localFolder/localFile.txt" should exist - But as "Brian" file "/folderB/fileB.txt" should not exist - - - Scenario: share receiver moves a whole share inside a local folder then moves the local folder inside a received share - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API - And user "Brian" moves folder "localFolder" to "folderA/localFolder" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - And as "Alice" folder "/folderA/localFolder" should exist - And as "Brian" folder "/folderA/localFolder" should exist - And as "Alice" file "/folderA/localFolder/localFile.txt" should exist - And as "Brian" file "/folderA/localFolder/localFile.txt" should exist - # folderB now exists separately, and is no longer inside localFolder - And as "Alice" file "/folderB/fileB.txt" should exist - And as "Brian" file "/folderB/fileB.txt" should exist - But as "Alice" folder "/folderA/localFolder/folderB" should not exist - And as "Brian" folder "/folderA/localFolder/folderB" should not exist - - - Scenario: share receiver moves a whole share inside a local folder then tries to move the share inside a received share - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API - And user "Brian" moves folder "localFolder/folderB" to "folderA/folderB" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 403" respectively - And as "Alice" file "/folderB/fileB.txt" should exist - And as "Brian" folder "/localFolder/folderB" should exist - And as "Brian" file "/localFolder/folderB/fileB.txt" should exist - But as "Alice" folder "/folderA/folderB" should not exist - And as "Brian" folder "/folderA/folderB" should not exist diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature deleted file mode 100644 index 240214d9bb..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature +++ /dev/null @@ -1,108 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - 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 "Brian" has uploaded file with content "some data" to "/textfile0.txt" - - @smokeTest - Scenario Outline: Sharee can see the share - Given using OCS API version "" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - When user "Brian" gets all the shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share_id should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: Sharee can see the filtered share - Given using OCS API version "" - And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" - And user "Brian" has uploaded file with content "some data" to "/textfile1.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Alice" has shared file "textfile1.txt" with user "Brian" - When user "Brian" gets all the shares shared with him that are received as file "textfile1 (2).txt" using the provisioning API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share_id should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: Sharee can't see the share that is filtered out - Given using OCS API version "" - And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" - And user "Brian" has uploaded file with content "some data" to "/textfile1.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Alice" has shared file "textfile1.txt" with user "Brian" - When user "Brian" gets all the shares shared with him that are received as file "textfile0 (2).txt" using the provisioning API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share id should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: Sharee can see the group share - Given using OCS API version "" - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - When user "Brian" gets all the shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share_id should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user should not be able to access a pending share (file) - Given using OCS API version "" - And auto-accept shares has been disabled - And user "Alice" has uploaded file with content "test data" to "/textfile1.txt" - When user "Alice" shares file "/textfile1.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "textfile1.txt" should not exist - And the sharing API should report to user "Brian" that these shares are in the pending state - | path | - | /textfile1.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user should not be able to access a pending share (folder) - Given using OCS API version "" - And auto-accept shares has been disabled - And user "Alice" has created folder "simple-folder" - And user "Alice" has created folder "simple-folder/sub" - And user "Alice" has uploaded file with content "test data" to "/simple-folder/textfile1.txt" - When user "Alice" shares file "/simple-folder" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" folder "simple-folder/" should not exist - And as "Brian" folder "simple-folder/sub" should not exist - And as "Brian" file "simple-folder/textfile1.txt" should not exist - And the sharing API should report to user "Brian" that these shares are in the pending state - | path | - | /simple-folder | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature deleted file mode 100644 index bc7779badb..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature +++ /dev/null @@ -1,111 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - - @smokeTest - Scenario Outline: moving a file into a share as recipient - Given using DAV path - And user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - When user "Brian" moves file "/textfile0.txt" to "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/shared/shared_file.txt" should exist - And as "Alice" file "/shared/shared_file.txt" should exist - Examples: - | dav-path-version | - | old | - | new | - - @smokeTest @files_trashbin-app-required - Scenario Outline: moving a file out of a share as recipient creates a backup for the owner - Given using DAV path - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared file "/shared" with user "Brian" - And user "Brian" has moved folder "/shared" to "/shared_renamed" - When user "Brian" moves file "/shared_renamed/shared_file.txt" to "/taken_out.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/taken_out.txt" should exist - And as "Alice" file "/shared/shared_file.txt" should not exist - And as "Alice" file "/shared_file.txt" should exist in the trashbin - Examples: - | dav-path-version | - | old | - | new | - - @files_trashbin-app-required - Scenario Outline: moving a folder out of a share as recipient creates a backup for the owner - Given using DAV path - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/sub" - And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" - And user "Alice" has shared file "/shared" with user "Brian" - And user "Brian" has moved folder "/shared" to "/shared_renamed" - When user "Brian" moves folder "/shared_renamed/sub" to "/taken_out" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/taken_out" should exist - And as "Alice" folder "/shared/sub" should not exist - And as "Alice" folder "/sub" should exist in the trashbin - And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin - Examples: - | dav-path-version | - | old | - | new | - - - Scenario: Move files between shares by same user - Given user "Alice" has created folder "share1" - And user "Alice" has created folder "share2" - And user "Alice" has moved file "textfile0.txt" to "share1/shared_file.txt" - And user "Alice" has shared folder "/share1" with user "Brian" - And user "Alice" has shared folder "/share2" with user "Brian" - When user "Brian" moves file "share1/shared_file.txt" to "share2/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "share1/shared_file.txt" should not exist - But as "Brian" file "share2/shared_file.txt" should exist - And as "Alice" file "share1/shared_file.txt" should not exist - But as "Alice" file "share2/shared_file.txt" should exist - - - Scenario: Move files between shares by same user added by sharee - Given user "Alice" has created folder "share1" - And user "Alice" has created folder "share2" - And user "Alice" has shared folder "/share1" with user "Brian" - And user "Alice" has shared folder "/share2" with user "Brian" - And user "Alice" has moved file "/textfile0.txt" to "share1/shared_file.txt" - When user "Brian" moves file "share1/shared_file.txt" to "share2/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "share2/shared_file.txt" should exist - And as "Alice" file "share2/shared_file.txt" should exist - - - Scenario: Move files between shares by different users - Given user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/PARENT" - And user "Brian" has created folder "/PARENT" - And user "Carol" has created folder "/PARENT" - And user "Alice" has moved file "textfile0.txt" to "PARENT/shared_file.txt" - And user "Alice" has shared folder "/PARENT" with user "Carol" - And user "Brian" has shared folder "/PARENT" with user "Carol" - When user "Carol" moves file "PARENT (2)/shared_file.txt" to "PARENT (3)/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Carol" file "PARENT (3)/shared_file.txt" should exist - And as "Brian" file "PARENT/shared_file.txt" should exist - But as "Alice" file "PARENT/shared_file.txt" should not exist - - - Scenario: overwrite a received file share - Given user "Alice" has uploaded file with content "this is the old content" to "/textfile1.txt" - And user "Alice" has shared file "/textfile1.txt" with user "Brian" - When user "Brian" uploads file with content "this is a new content" to "/textfile1.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" file "/textfile1.txt" should exist - And the content of file "/textfile1.txt" for user "Brian" should be "this is a new content" - And the content of file "/textfile1.txt" for user "Alice" should be "this is a new content" diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature deleted file mode 100644 index 0256b0aae3..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature +++ /dev/null @@ -1,151 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - - @smokeTest - Scenario Outline: getting all shares of a user using that user - Given using OCS API version "" - And user "Alice" has moved file "/textfile0.txt" to "/file_to_share.txt" - And user "Alice" has shared file "file_to_share.txt" with user "Brian" - When user "Alice" gets all shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And file "file_to_share.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting all shares of a user using another user - Given using OCS API version "" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - When the administrator gets all shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And file "textfile0.txt" should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: getting all shares of a file - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Carol | - | David | - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Alice" has shared file "textfile0.txt" with user "Carol" - When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should be included in the response - And user "Carol" should be included in the response - And user "David" should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: getting all shares of a file with reshares - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Carol | - | David | - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Brian" has shared file "textfile0.txt" with user "Carol" - When user "Alice" gets all the shares with reshares from the file "textfile0.txt" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should be included in the response - And user "Carol" should be included in the response - And user "David" should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @smokeTest - Scenario Outline: User's own shares reshared to him don't appear when getting "shared with me" shares - Given using OCS API version "" - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Carol" has been added to group "grp1" - And user "Carol" has created folder "/shared" - And user "Carol" has uploaded file "/filesForUpload/textfile.txt" to "/shared/shared_file.txt" - And user "Carol" has shared folder "/shared" with user "Brian" - And user "Brian" has shared folder "/shared" with group "grp1" - When user "Carol" gets all the shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the last share id should not be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @issue-ocis-reva-374 - Scenario Outline: Get a share with a user that didn't receive the share - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Carol" has uploaded file "/filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - When user "Carol" 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 "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @skipOnLDAP - Scenario Outline: Share of folder to a group, remove user from that group - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And group "group0" has been created - And user "Brian" has been added to group "group0" - And user "Carol" has been added to group "group0" - And user "Alice" has created folder "/PARENT" - And user "Alice" has moved file "textfile0.txt" to "PARENT/parent.txt" - And user "Alice" has shared folder "/PARENT" with group "group0" - When the administrator removes user "Carol" from group "group0" using the provisioning API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - And user "Carol" should see the following elements - | textfile0.txt | - But user "Carol" should not see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting all the shares inside the folder - Given using OCS API version "" - And user "Alice" has created folder "/PARENT" - And user "Alice" has moved file "textfile0.txt" to "PARENT/parent.txt" - And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" - When user "Alice" gets all the shares inside the folder "PARENT" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And file "parent.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature deleted file mode 100644 index a9989a316f..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature +++ /dev/null @@ -1,57 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: get the received shares filtered by type (user, group etc) - As a user - I want to be able to know the shares that I have received of a particular type (user, group etc) - So that I can reduce the amount of data that has to be transferred to be just the data that I need - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/folderToShareWithUser" - And user "Alice" has created folder "/folderToShareWithGroup" - And user "Alice" has created folder "/folderToShareWithPublic" - And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" - And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" - And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - - - Scenario Outline: getting shares received from users - Given using OCS API version "" - When user "Brian" gets the user shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 2 files or folders should be included in the response - And folder "folderToShareWithUser" should be included in the response - And file "fileToShareWithUser.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares received from groups - Given using OCS API version "" - When user "Brian" gets the group shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 2 files or folders should be included in the response - And folder "folderToShareWithGroup" should be included in the response - And folder "fileToShareWithGroup.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature deleted file mode 100644 index b0d8bfd18f..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature +++ /dev/null @@ -1,84 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: get the received shares filtered by type (user, group etc) - As a user - I want to be able to know the shares that I have received of a particular type (user, group etc) - So that I can reduce the amount of data that has to be transferred to be just the data that I need - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/folderToShareWithUser" - And user "Alice" has created folder "/folderToShareWithGroup" - And user "Alice" has created folder "/folderToShareWithPublic" - And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" - And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" - And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" - - - Scenario Outline: getting shares received from users when there are none - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - When user "Brian" gets the user shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares received from groups when there are none - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - When user "Brian" gets the group shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares received from public links when there are none - # Note: public links are purposely created in this scenario - # users do not receive public links, so asking for a list of public links - # that are "shared with me" should always return an empty list. - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - When user "Brian" gets the public link shares shared with him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature deleted file mode 100644 index d066eb58f7..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature +++ /dev/null @@ -1,87 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: get shares filtered by type (user, group etc) - As a user - I want to be able to know the shares that I have made of a particular type (user, group etc) - So that I can reduce the amount of data that has to be transferred to be just the data that I need - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/folderToShareWithUser" - And user "Alice" has created folder "/folderToShareWithGroup" - And user "Alice" has created folder "/folderToShareWithPublic" - And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" - And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" - And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - - - Scenario Outline: getting shares shared to users - Given using OCS API version "" - When user "Alice" gets the user shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 2 files or folders should be included in the response - And folder "folderToShareWithUser" should be included in the response - And file "fileToShareWithUser.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares shared to groups - Given using OCS API version "" - When user "Alice" gets the group shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 2 files or folders should be included in the response - And folder "folderToShareWithGroup" should be included in the response - And folder "fileToShareWithGroup.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares shared to public links - Given using OCS API version "" - When user "Alice" gets the public link shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 2 files or folders should be included in the response - And folder "folderToShareWithPublic" should be included in the response - And folder "fileToShareWithPublic.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares shared to users and groups - Given using OCS API version "" - When user "Alice" gets the user and group shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And exactly 4 files or folders should be included in the response - And folder "folderToShareWithUser" should be included in the response - And file "fileToShareWithUser.txt" should be included in the response - And folder "folderToShareWithGroup" should be included in the response - And folder "fileToShareWithGroup.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature deleted file mode 100644 index dab91cdec5..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature +++ /dev/null @@ -1,75 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: get shares filtered by type (user, group etc) - As a user - I want to be able to know the shares that I have made of a particular type (user, group etc) - So that I can reduce the amount of data that has to be transferred to be just the data that I need - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/folderToShareWithUser" - And user "Alice" has created folder "/folderToShareWithGroup" - And user "Alice" has created folder "/folderToShareWithPublic" - And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" - And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" - And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" - - - Scenario Outline: getting shares shared to users when there are none - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - When user "Alice" gets the user shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares shared to groups when there are none - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has created a public link share with settings - | path | /folderToShareWithPublic | - | permissions | read | - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has created a public link share with settings - | path | /fileToShareWithPublic.txt | - | permissions | read | - When user "Alice" gets the group shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: getting shares shared to public links when there are none - Given using OCS API version "" - And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" - And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" - And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" - And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" - When user "Alice" gets the public link shares shared by him using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And no files or folders should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature deleted file mode 100644 index 693c988e03..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature +++ /dev/null @@ -1,319 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given using OCS API version "1" - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario Outline: Correct webdav share-permissions for owned file - Given using DAV path - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - When user "Alice" gets the following properties of file "/tmp.txt" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "201" - And the single response should contain a property "ocs:share-permissions" with value "19" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received file with edit and reshare permissions - Given using DAV path - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has shared file "/tmp.txt" with user "Brian" - When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "19" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared file with edit and reshare permissions - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has created a share with settings - | path | /tmp.txt | - | shareType | group | - | permissions | share,update,read | - | shareWith | grp1 | - When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "19" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received file with edit permissions but no reshare permissions - Given using DAV path - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has shared file "tmp.txt" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | update,read | - Then the HTTP status code should be "200" - And as user "Brian" file "/tmp.txt" should contain a property "ocs:share-permissions" with value "3" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared file with edit permissions but no reshare permissions - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has created a share with settings - | path | /tmp.txt | - | shareType | group | - | permissions | update,read | - | shareWith | grp1 | - When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "3" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received file with reshare permissions but no edit permissions - Given using DAV path - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has shared file "tmp.txt" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | share,read | - Then the HTTP status code should be "200" - And as user "Brian" file "/tmp.txt" should contain a property "ocs:share-permissions" with value "17" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file with content "foo" to "/tmp.txt" - And user "Alice" has created a share with settings - | path | /tmp.txt | - | shareType | group | - | permissions | share,read | - | shareWith | grp1 | - When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "17" - Examples: - | dav-path | - | old | - | new | - - - - Scenario Outline: Correct webdav share-permissions for owned folder - Given using DAV path - And user "Alice" has created folder "/tmp" - When user "Alice" gets the following properties of folder "/" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "201" - And the single response should contain a property "ocs:share-permissions" with value "31" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received folder with all permissions - Given using DAV path - And user "Alice" has created folder "/tmp" - And user "Alice" has shared file "/tmp" with user "Brian" - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "31" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/tmp" - And user "Alice" has created a share with settings - | path | tmp | - | shareType | group | - | shareWith | grp1 | - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "31" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received folder with all permissions but edit - Given using DAV path - And user "Alice" has created folder "/tmp" - And user "Alice" has shared file "/tmp" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | share,delete,create,read | - Then the HTTP status code should be "200" - And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "29" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but edit - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/tmp" - And user "Alice" has created a share with settings - | path | tmp | - | shareType | group | - | shareWith | grp1 | - | permissions | share,delete,create,read | - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "29" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received folder with all permissions but create - Given using DAV path - And user "Alice" has created folder "/tmp" - And user "Alice" has shared file "/tmp" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | share,delete,update,read | - Then the HTTP status code should be "200" - And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "27" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but create - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/tmp" - And user "Alice" has created a share with settings - | path | tmp | - | shareType | group | - | shareWith | grp1 | - | permissions | share,delete,update,read | - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "27" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received folder with all permissions but delete - Given using DAV path - And user "Alice" has created folder "/tmp" - And user "Alice" has shared file "/tmp" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the HTTP status code should be "200" - And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "23" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but delete - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/tmp" - And user "Alice" has created a share with settings - | path | tmp | - | shareType | group | - | shareWith | grp1 | - | permissions | share,create,update,read | - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "23" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received folder with all permissions but share - Given using DAV path - And user "Alice" has created folder "/tmp" - And user "Alice" has shared file "/tmp" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | change | - Then the HTTP status code should be "200" - And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "15" - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but share - Given using DAV path - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "/tmp" - And user "Alice" has created a share with settings - | path | tmp | - | shareType | group | - | shareWith | grp1 | - | permissions | change | - When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API - | propertyName | - | ocs:share-permissions | - Then the HTTP status code should be "200" - And the single response should contain a property "ocs:share-permissions" with value "15" - Examples: - | dav-path | - | old | - | new | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature deleted file mode 100644 index c128edf8e1..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature +++ /dev/null @@ -1,71 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share access by ID - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: Get a share with a valid share ID - Given using OCS API version "" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - And user "Alice" gets share with id "%last_share_id%" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_with | %username% | - | share_with_displayname | %displayname% | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: accept a share using the share Id - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And using OCS API version "" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - And user "Brian" accepts share with ID "%last_share_id%" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should see the following elements - | /textfile0.txt | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | /textfile0.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: decline a share using the share Id - Given using OCS API version "" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - And user "Brian" declines share with ID "%last_share_id%" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should not see the following elements - | /textfile0.txt | - And the sharing API should report to user "Brian" that these shares are in the declined state - | path | - | /textfile0.txt | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature deleted file mode 100644 index 6204a0ca6a..0000000000 --- a/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature +++ /dev/null @@ -1,248 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - - - Scenario: Uploading file to a user read-only share folder does not work - Given user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | user | - | permissions | read | - | shareWith | Brian | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/FOLDER/textfile.txt" should not exist - - - Scenario Outline: Uploading file to a group read-only share folder does not work - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | group | - | permissions | read | - | shareWith | grp1 | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/FOLDER/textfile.txt" should not exist - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading file to a user upload-only share folder works - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | user | - | permissions | create | - | shareWith | Brian | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the following headers should match these regular expressions for user "Brian" - | ETag | /^"[a-f0-9:\.]{1,32}"$/ | - And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading file to a group upload-only share folder works - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | group | - | permissions | create | - | shareWith | grp1 | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the following headers should match these regular expressions for user "Brian" - | ETag | /^"[a-f0-9:\.]{1,32}"$/ | - And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | dav-path | - | old | - | new | - - @smokeTest - Scenario Outline: Uploading file to a user read/write share folder works - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | user | - | permissions | change | - | shareWith | Brian | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading file to a group read/write share folder works - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | dav-path | - | old | - | new | - - @smokeTest @skipOnGraph - Scenario Outline: Check quota of owners parent directory of a shared file - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And the quota of user "Brian" has been set to "0" - And user "Alice" has uploaded file with content "some data" to "myfile.txt" - And user "Alice" has shared file "myfile.txt" with user "Brian" - When user "Brian" uploads file "filesForUpload/textfile.txt" to "/myfile.txt" using the WebDAV API - Then the HTTP status code should be "204" - And the following headers should match these regular expressions for user "Brian" - | ETag | /^"[a-f0-9:\.]{1,32}"$/ | - And the content of file "/myfile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading to a user shared folder with read/write permission when the sharer has unsufficient quota does not work - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | user | - | permissions | change | - | shareWith | Brian | - And the quota of user "Alice" has been set to "0" - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API - Then the HTTP status code should be "507" - And as "Alice" file "/FOLDER/myfile.txt" should not exist - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading to a group shared folder with read/write permission when the sharer has unsufficient quota does not work - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - And the quota of user "Alice" has been set to "0" - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API - Then the HTTP status code should be "507" - And as "Alice" file "/FOLDER/myfile.txt" should not exist - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading to a user shared folder with upload-only permission when the sharer has insufficient quota does not work - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | user | - | permissions | create | - | shareWith | Brian | - And the quota of user "Alice" has been set to "0" - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API - Then the HTTP status code should be "507" - And as "Alice" file "/FOLDER/myfile.txt" should not exist - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: Uploading to a group shared folder with upload-only permission when the sharer has insufficient quota does not work - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has created a share with settings - | path | FOLDER | - | shareType | group | - | permissions | create | - | shareWith | grp1 | - And the quota of user "Alice" has been set to "0" - When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API - Then the HTTP status code should be "507" - And as "Alice" file "/FOLDER/myfile.txt" should not exist - Examples: - | dav-path | - | old | - | new | - - - Scenario: Uploading a file in to a shared folder without edit permissions - Given using new DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/READ_ONLY" - And user "Alice" has created a share with settings - | path | /READ_ONLY | - | shareType | user | - | permissions | read | - | shareWith | Brian | - When user "Brian" uploads the following chunks to "/READ_ONLY/myfile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | hallo | - | 2 | welt | - Then the HTTP status code should be "403" - And as "Alice" file "/FOLDER/myfile.txt" should not exist diff --git a/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature deleted file mode 100644 index f6fd4c8614..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature +++ /dev/null @@ -1,275 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - - @smokeTest - Scenario Outline: User is not allowed to reshare file when reshare permission is not given - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update" - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" file "/textfile0.txt" should not exist - But as "Brian" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: User is not allowed to reshare folder when reshare permission is not given - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update" - When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "read,update" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "/FOLDER" should not exist - But as "Brian" folder "/FOLDER" should exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @smokeTest - Scenario Outline: User is allowed to reshare file with the same permissions - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,read" - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is allowed to reshare folder with the same permissions - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read" - When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "share,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" folder "/FOLDER" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is allowed to reshare file with less permissions - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read" - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is allowed to reshare folder with less permissions - Given using OCS API version "" - And user "Alice" has created folder "/FOLDER" - And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read" - When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "share,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" folder "/FOLDER" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is not allowed to reshare file and set more permissions bits - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" file "/textfile0.txt" should not exist - But as "Brian" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | http_status_code | received_permissions | reshare_permissions | - # passing on more bits including reshare - | 1 | 200 | 17 | 19 | - | 2 | 404 | 17 | 19 | - | 1 | 200 | 17 | 23 | - | 2 | 404 | 17 | 23 | - | 1 | 200 | 17 | 31 | - | 2 | 404 | 17 | 31 | - # passing on more bits but not reshare - | 1 | 200 | 17 | 3 | - | 2 | 404 | 17 | 3 | - | 1 | 200 | 17 | 7 | - | 2 | 404 | 17 | 7 | - | 1 | 200 | 17 | 15 | - | 2 | 404 | 17 | 15 | - - - Scenario Outline: User is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Brian" sharing with user "Carol" should include - | share_with | %username% | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | | - | uid_owner | %username% | - And as "Carol" file "/textfile0.txt" should exist - # The receiver of the reshare can always delete their received share, even though they do not have delete permission - And user "Carol" should be able to delete file "/textfile0.txt" - # But the upstream sharers will still have the file - But as "Brian" file "/textfile0.txt" should exist - And as "Alice" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | received_permissions | reshare_permissions | granted_permissions | - | 1 | 100 | 19 | 23 | 19 | - | 2 | 200 | 19 | 23 | 19 | - | 1 | 100 | 19 | 31 | 19 | - | 2 | 200 | 19 | 31 | 19 | - | 1 | 100 | 19 | 7 | 3 | - | 2 | 200 | 19 | 7 | 3 | - | 1 | 100 | 19 | 15 | 3 | - | 2 | 200 | 19 | 15 | 3 | - | 1 | 100 | 17 | 21 | 17 | - | 2 | 200 | 17 | 21 | 17 | - | 1 | 100 | 17 | 5 | 1 | - | 2 | 200 | 17 | 5 | 1 | - | 1 | 100 | 17 | 25 | 17 | - | 2 | 200 | 17 | 25 | 17 | - | 1 | 100 | 17 | 9 | 1 | - | 2 | 200 | 17 | 9 | 1 | - - - Scenario Outline: User is not allowed to reshare folder and set more permissions bits - Given using OCS API version "" - And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions - When user "Brian" shares folder "/PARENT" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "/PARENT" should not exist - But as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | http_status_code | received_permissions | reshare_permissions | - # try to pass on more bits including reshare - | 1 | 200 | 17 | 19 | - | 2 | 404 | 17 | 19 | - | 1 | 200 | 17 | 21 | - | 2 | 404 | 17 | 21 | - | 1 | 200 | 17 | 23 | - | 2 | 404 | 17 | 23 | - | 1 | 200 | 17 | 31 | - | 2 | 404 | 17 | 31 | - | 1 | 200 | 19 | 23 | - | 2 | 404 | 19 | 23 | - | 1 | 200 | 19 | 31 | - | 2 | 404 | 19 | 31 | - # try to pass on more bits but not reshare - | 1 | 200 | 17 | 3 | - | 2 | 404 | 17 | 3 | - | 1 | 200 | 17 | 5 | - | 2 | 404 | 17 | 5 | - | 1 | 200 | 17 | 7 | - | 2 | 404 | 17 | 7 | - | 1 | 200 | 17 | 15 | - | 2 | 404 | 17 | 15 | - | 1 | 200 | 19 | 7 | - | 2 | 404 | 19 | 7 | - | 1 | 200 | 19 | 15 | - | 2 | 404 | 19 | 15 | - - - Scenario Outline: User is not allowed to reshare folder and add delete permission bit (8) - Given using OCS API version "" - And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions - When user "Brian" shares folder "/PARENT" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "/PARENT" should not exist - But as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | http_status_code | received_permissions | reshare_permissions | - # try to pass on extra delete (including reshare) - | 1 | 200 | 17 | 25 | - | 2 | 404 | 17 | 25 | - | 1 | 200 | 19 | 27 | - | 2 | 404 | 19 | 27 | - | 1 | 200 | 23 | 31 | - | 2 | 404 | 23 | 31 | - # try to pass on extra delete (but not reshare) - | 1 | 200 | 17 | 9 | - | 2 | 404 | 17 | 9 | - | 1 | 200 | 19 | 11 | - | 2 | 404 | 19 | 11 | - | 1 | 200 | 23 | 15 | - | 2 | 404 | 23 | 15 | - - - Scenario Outline: Reshare a file with same name as a deleted file - Given using OCS API version "" - 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 "Alice" has deleted file "textfile0.txt" - And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Reshare a folder with same name as a deleted folder - Given using OCS API version "" - And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Alice" has deleted folder "PARENT" - And user "Alice" has created folder "/PARENT" - When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" folder "/PARENT" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Reshare a folder with same name as a deleted file - Given using OCS API version "" - 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 "Alice" has deleted file "textfile0.txt" - And user "Alice" has created folder "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" folder "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature deleted file mode 100644 index 61b3262b34..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature +++ /dev/null @@ -1,22 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: resharing can be done on a reshared resource - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario: Reshared files can be still accessed if a user in the middle removes it. - Given user "Carol" has been created with default attributes and without skeleton files - And user "David" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Brian" has moved file "/textfile0.txt" to "/textfile0_shared.txt" - And user "Brian" has shared file "textfile0_shared.txt" with user "Carol" - And user "Carol" has shared file "textfile0_shared.txt" with user "David" - When user "Brian" deletes file "/textfile0_shared.txt" using the WebDAV API - Then the HTTP status code should be "204" - And the content of file "/textfile0_shared.txt" for user "Carol" should be "ownCloud test text file 0" - And the content of file "/textfile0_shared.txt" for user "David" should be "ownCloud test text file 0" diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature deleted file mode 100644 index 832fe19a97..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature +++ /dev/null @@ -1,38 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: resharing can be disabled - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario Outline: resharing a file is not allowed when allow resharing has been disabled - Given using OCS API version "" - And user "Carol" 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" with permissions "share,update,read" - And parameter "shareapi_allow_resharing" of app "core" has been set to "no" - When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,update,read" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" file "/textfile0.txt" should not exist - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled - Given using OCS API version "" - And parameter "shareapi_allow_resharing" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "/textfile0.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature deleted file mode 100644 index 69afb8c892..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature +++ /dev/null @@ -1,143 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: a subfolder of a received share can be reshared - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario Outline: User is allowed to reshare a sub-folder with the same permissions - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/TMP" - And user "Alice" has created folder "/TMP/SUB" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" - When user "Brian" shares folder "/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" folder "/SUB" should exist - And as "Brian" folder "/TMP/SUB" should exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is not allowed to reshare a sub-folder with more permissions - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/TMP" - And user "Alice" has created folder "/TMP/SUB" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions - When user "Brian" shares folder "/TMP/SUB" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "/SUB" should not exist - But as "Brian" folder "/TMP/SUB" should exist - Examples: - | ocs_api_version | http_status_code | received_permissions | reshare_permissions | - # try to pass on more bits including reshare - | 1 | 200 | 17 | 19 | - | 2 | 404 | 17 | 19 | - | 1 | 200 | 17 | 21 | - | 2 | 404 | 17 | 21 | - | 1 | 200 | 17 | 23 | - | 2 | 404 | 17 | 23 | - | 1 | 200 | 17 | 31 | - | 2 | 404 | 17 | 31 | - | 1 | 200 | 19 | 23 | - | 2 | 404 | 19 | 23 | - | 1 | 200 | 19 | 31 | - | 2 | 404 | 19 | 31 | - # try to pass on more bits but not reshare - | 1 | 200 | 17 | 3 | - | 2 | 404 | 17 | 3 | - | 1 | 200 | 17 | 5 | - | 2 | 404 | 17 | 5 | - | 1 | 200 | 17 | 7 | - | 2 | 404 | 17 | 7 | - | 1 | 200 | 17 | 15 | - | 2 | 404 | 17 | 15 | - | 1 | 200 | 19 | 7 | - | 2 | 404 | 19 | 7 | - | 1 | 200 | 19 | 15 | - | 2 | 404 | 19 | 15 | - # try to pass on extra delete (including reshare) - | 1 | 200 | 17 | 25 | - | 2 | 404 | 17 | 25 | - | 1 | 200 | 19 | 27 | - | 2 | 404 | 19 | 27 | - | 1 | 200 | 23 | 31 | - | 2 | 404 | 23 | 31 | - # try to pass on extra delete (but not reshare) - | 1 | 200 | 17 | 9 | - | 2 | 404 | 17 | 9 | - | 1 | 200 | 19 | 11 | - | 2 | 404 | 19 | 11 | - | 1 | 200 | 23 | 15 | - | 2 | 404 | 23 | 15 | - - - Scenario Outline: User is allowed to update reshare of a sub-folder with less permissions - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/TMP" - And user "Alice" has created folder "/TMP/SUB" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,create,update,read" - When user "Brian" updates the last share using the sharing API with - | permissions | share,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" folder "/SUB" should exist - But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" - And as "Brian" folder "/TMP/SUB" should exist - And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is allowed to update reshare of a sub-folder to the maximum allowed permissions - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/TMP" - And user "Alice" has created folder "/TMP/SUB" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,read" - When user "Brian" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Carol" folder "/SUB" should exist - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" - And as "Brian" folder "/TMP/SUB" should exist - And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: User is not allowed to update reshare of a sub-folder with more permissions - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/TMP" - And user "Alice" has created folder "/TMP/SUB" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" - And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,read" - When user "Brian" updates the last share using the sharing API with - | permissions | all | - Then the OCS status code should be "404" - And the HTTP status code should be "" - And as "Carol" folder "/SUB" should exist - But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" - And as "Brian" folder "/TMP/SUB" should exist - But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature deleted file mode 100644 index 6f8986adb9..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature +++ /dev/null @@ -1,44 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: resharing a resource with an expiration date - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: User should not be able to re-share a folder to a group which he/she is not member of when share with only member group is enabled - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" shares folder "/PARENT" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Carol" folder "/PARENT" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 403 | 200 | - | 2 | 403 | 403 | - - - Scenario Outline: User should not be able to re-share a file to a group which he/she is not member of when share with only member group is enabled - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" shares folder "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Carol" folder "/textfile0.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 403 | 200 | - | 2 | 403 | 403 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature deleted file mode 100644 index b53231e3fe..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature +++ /dev/null @@ -1,142 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - - - Scenario Outline: Update of reshare can reduce permissions - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,create,update,read" - When user "Brian" updates the last share using the sharing API with - | permissions | share,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Update of reshare can increase permissions to the maximum allowed - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" - When user "Brian" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Do not allow update of reshare to exceed permissions - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" - When user "Brian" updates the last share using the sharing API with - | permissions | all | - Then the OCS status code should be "404" - And the HTTP status code should be "" - And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: Update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" - When user "Alice" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" - When user "Alice" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Update of group reshare by the original share owner can increase permissions up to permissions of the top-level share - Given using OCS API version "" - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP" with group "grp1" with permissions "share,read" - When user "Alice" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share - Given using OCS API version "" - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" - And user "Brian" has shared folder "/TMP" with group "grp1" with permissions "share,read" - When user "Alice" updates the last share using the sharing API with - | permissions | share,create,update,read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: After losing share permissions user can still delete a previously reshared share - Given using OCS API version "" - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" - And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,create,update,read" - And user "Alice" has updated the last share of "Alice" with - | permissions | create,update,read | - 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 "" - And user "Carol" should not have any received shares - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature deleted file mode 100644 index fb7dd11c42..0000000000 --- a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature +++ /dev/null @@ -1,416 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: resharing a resource with an expiration date - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - - - Scenario Outline: User should be able to set expiration while resharing a file with user - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +3 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | +3 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +3 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @issue-ocis-reva-194 - Scenario Outline: User should be able to set expiration while resharing a file with group - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - | expireDate | +3 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | +3 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +3 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: resharing with user using the sharing API with expire days set and combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +30 days | 100 | - | 2 | yes | yes | +30 days | 200 | - | 1 | no | yes | | 100 | - | 2 | no | yes | | 200 | - - @issue-ocis-reva-194 - Scenario Outline: resharing with group using the sharing API with expire days set and combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +30 days | 100 | - | 2 | yes | yes | +30 days | 200 | - | 1 | no | yes | | 100 | - | 2 | no | yes | | 200 | - - - Scenario Outline: resharing with user using the sharing API without expire days set and with combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +7 days | 100 | - | 2 | yes | yes | +7 days | 200 | - | 1 | no | yes | | 100 | - | 2 | no | yes | | 200 | - - @issue-ocis-reva-194 - Scenario Outline: resharing with group using the sharing API without expire days set and with combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +7 days | 100 | - | 2 | yes | yes | +7 days | 200 | - | 1 | no | yes | | 100 | - | 2 | no | yes | | 200 | - - - Scenario Outline: resharing with user using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +20 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +20 days | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | - | 1 | yes | yes | 100 | - | 2 | yes | yes | 200 | - | 1 | no | yes | 100 | - | 2 | no | yes | 200 | - - @issue-ocis-reva-194 - Scenario Outline: resharing with group using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share - Given using OCS API version "" - And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | group | - | permissions | change | - | shareWith | grp1 | - | expireDate | +20 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +20 days | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | - | 1 | yes | yes | 100 | - | 2 | yes | yes | 200 | - | 1 | no | yes | 100 | - | 2 | no | yes | 200 | - - - Scenario Outline: Setting default expiry date and enforcement after the share is created - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - And user "Brian" has shared file "/textfile0.txt" with user "Carol" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "4" - When user "Brian" gets the info of the last share using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | - | 1 | yes | yes | 100 | - | 2 | yes | yes | 200 | - | 1 | no | yes | 100 | - | 2 | no | yes | 200 | - - @issue-ocis-reva-194 - Scenario Outline: resharing group share with user using the sharing API with default expire date set and with combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +30 days | 100 | - | 2 | yes | yes | +30 days | 200 | - | 1 | no | yes | | 100 | - | 2 | no | yes | | 200 | - - @issue-ocis-reva-194 - Scenario Outline: resharing group share with user using the sharing API with default expire date set and specifying expiration on share and with combinations of default/enforce expire date enabled - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And group "grp1" has been created - And user "Carol" has been created with default attributes and without skeleton files - And user "Brian" has been added to group "grp1" - And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +20 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | - | 1 | yes | yes | +20 days | 100 | - | 2 | yes | yes | +20 days | 200 | - | 1 | no | yes | +20 days | 100 | - | 2 | no | yes | +20 days | 200 | - - - Scenario Outline: resharing using the sharing API with default expire date set but not enforced - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Brian" should include - | expiration | | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | - | 1 | yes | no | 100 | - | 2 | yes | no | 200 | - | 1 | no | no | 100 | - | 2 | no | no | 200 | - - @issue-37013 - Scenario Outline: reshare extends the received expiry date up to the default by default - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Alice" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code | - | 1 | yes | yes | +30 days | 100 | - | 2 | yes | yes | +30 days | 200 | - | 1 | yes | no | | 100 | - | 2 | yes | no | | 200 | - | 1 | no | no | | 100 | - | 2 | no | no | | 200 | - - @issue-37013 - Scenario Outline: reshare can extend the received expiry date further into the future - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +40 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the information of the last share of user "Alice" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +40 days | - Examples: - | ocs_api_version | default-expire-date | ocs_status_code | - | 1 | yes | 100 | - | 2 | yes | 200 | - | 1 | no | 100 | - | 2 | no | 200 | - - @issue-37013 - Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - When user "Brian" creates a share using the sharing API with settings - | path | textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +40 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the information of the last share of user "Alice" should include - | expiration | +20 days | - Examples: - | ocs_api_version | default-expire-date | http_status_code | - | 1 | yes | 200 | - | 2 | yes | 404 | diff --git a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature deleted file mode 100644 index 29188e4c74..0000000000 --- a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature +++ /dev/null @@ -1,315 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: sharing - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @smokeTest - Scenario Outline: Allow modification of reshare - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "/TMP" - And user "Alice" has shared folder "TMP" with user "Brian" - And user "Brian" has shared folder "TMP" with user "Carol" - When user "Brian" updates the last share using the sharing API with - | permissions | read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile.txt" - And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: keep group permissions in sync - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - And user "Brian" has created folder "FOLDER" - And user "Brian" has moved file "/textfile0.txt" to "/FOLDER/textfile0.txt" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | id | A_STRING | - | item_type | file | - | item_source | A_STRING | - | share_type | group | - | file_source | A_STRING | - | file_target | /textfile0.txt | - | permissions | read | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | mimetype | text/plain | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Cannot set permissions to zero - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has created folder "/FOLDER" - And user "Alice" has shared folder "/FOLDER" with group "grp1" - When user "Alice" updates the last share using the sharing API with - | permissions | 0 | - Then the OCS status code should be "400" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 400 | - - - Scenario Outline: Cannot update a share of a file with a user to have only create and/or delete permission - Given using OCS API version "" - And 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" - When user "Alice" updates the last share using the sharing API with - | permissions | | - Then the OCS status code should be "400" - And the HTTP status code should be "" - # Brian should still have at least read access to the shared file - And as "Brian" entry "textfile0.txt" should exist - Examples: - | ocs_api_version | http_status_code | permissions | - | 1 | 200 | create | - | 2 | 400 | create | - | 1 | 200 | delete | - | 2 | 400 | delete | - | 1 | 200 | create,delete | - | 2 | 400 | create,delete | - - - Scenario Outline: Cannot update a share of a file with a group to have only create and/or delete permission - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - When user "Alice" updates the last share using the sharing API with - | permissions | | - Then the OCS status code should be "400" - And the HTTP status code should be "" - # Brian in grp1 should still have at least read access to the shared file - And as "Brian" entry "textfile0.txt" should exist - Examples: - | ocs_api_version | http_status_code | permissions | - | 1 | 200 | create | - | 2 | 400 | create | - | 1 | 200 | delete | - | 2 | 400 | delete | - | 1 | 200 | create,delete | - | 2 | 400 | create,delete | - - @skipOnFilesClassifier @issue-files-classifier-291 - Scenario: Share ownership change after moving a shared file outside of an outer share - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "/folder1" - And user "Alice" has created folder "/folder1/folder2" - And user "Brian" has created folder "/moved-out" - And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all" - And user "Brian" has shared folder "/folder1/folder2" with user "Carol" with permissions "all" - When user "Brian" moves folder "/folder1/folder2" to "/moved-out/folder2" using the WebDAV API - Then the HTTP status code should be "201" - And the response when user "Brian" gets the info of the last share should include - | id | A_STRING | - | item_type | folder | - | item_source | A_STRING | - | share_type | user | - | file_source | A_STRING | - | file_target | /folder2 | - | permissions | all | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | mimetype | httpd/unix-directory | - And as "Alice" folder "/folder1/folder2" should not exist - And as "Carol" folder "/folder2" should exist - - - Scenario: Share ownership change after moving a shared file to another share - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "/Alice-folder" - And user "Alice" has created folder "/Alice-folder/folder2" - And user "Carol" has created folder "/Carol-folder" - And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all" - And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all" - When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API - Then the HTTP status code should be "201" - And the response when user "Carol" gets the info of the last share should include - | id | A_STRING | - | item_type | folder | - | item_source | A_STRING | - | share_type | user | - | file_source | A_STRING | - | file_target | /Carol-folder | - | permissions | all | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | mimetype | httpd/unix-directory | - And as "Alice" folder "/Alice-folder/folder2" should not exist - And as "Carol" folder "/Carol-folder/folder2" should exist - - - Scenario Outline: Increasing permissions is allowed for owner - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Carol" has created folder "/FOLDER" - And user "Carol" has shared folder "/FOLDER" with group "grp1" - And user "Carol" has updated the last share with - | permissions | read | - When user "Carol" updates the last share using the sharing API with - | permissions | all | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Forbid sharing with groups - Given using OCS API version "" - And group "grp1" has been created - And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - - Scenario Outline: Editing share permission of existing share is forbidden when sharing with groups is forbidden - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - When user "Alice" updates the last share using the sharing API with - | permissions | read, create | - Then the OCS status code should be "400" - And the HTTP status code should be "" - And the response when user "Alice" gets the info of the last share should include - | item_type | file | - | item_source | A_STRING | - | share_type | group | - | file_target | /textfile0.txt | - | permissions | read, update, share | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 400 | - - - Scenario Outline: Deleting group share is allowed when sharing with groups is forbidden - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - When user "Alice" deletes the last share using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - When user "Alice" gets the info of the last share using the sharing API - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the last response should be empty - Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 404 | - - - Scenario Outline: user can update the role in an existing share after the system maximum expiry date has been reduced - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And 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 created a share with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +30 days | - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "5" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the response when user "Alice" gets the info of the last share should include - | permissions | read | - | expiration | +30 days | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: user cannot concurrently update the role and date in an existing share after the system maximum expiry date has been reduced - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And 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 created a share with settings - | path | textfile0.txt | - | shareType | user | - | shareWith | Brian | - | permissions | read,share | - | expireDate | +30 days | - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "10" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - | expireDate | +28 days | - Then the OCS status message should be "Cannot set expiration date more than 10 days in the future" - And the HTTP status code should be "" - And the OCS status code should be "404" - And the response when user "Brian" gets the info of the last share should include - | permissions | read, share | - | expiration | +30 days | - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature deleted file mode 100644 index acee69c2f9..0000000000 --- a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature +++ /dev/null @@ -1,49 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: updating shares to users and groups that have the same name - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - And group "Brian" has been created - And user "Carol" has been added to group "Brian" - And user "Alice" has created folder "/TMP" - And user "Alice" has uploaded file with content "Random data" to "/TMP/randomfile.txt" - - @skipOnLDAP - Scenario Outline: update permissions of a user share with a user and a group having the same name - Given using OCS API version "" - And user "Alice" has shared folder "/TMP" with group "Brian" - And user "Alice" has shared folder "/TMP" with user "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the content of file "/TMP/randomfile.txt" for user "Brian" should be "Random data" - And the content of file "/TMP/randomfile.txt" for user "Carol" should be "Random data" - And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Carol.txt" - But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Brian.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnLDAP - Scenario Outline: update permissions of a group share with a user and a group having the same name - Given using OCS API version "" - And user "Alice" has shared folder "/TMP" with user "Brian" - And user "Alice" has shared folder "/TMP" with group "Brian" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And the content of file "/TMP/randomfile.txt" for user "Brian" should be "Random data" - And the content of file "/TMP/randomfile.txt" for user "Carol" should be "Random data" - And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Carol.txt" - But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Brian.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature b/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature deleted file mode 100644 index bd3ec2b7b6..0000000000 --- a/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature +++ /dev/null @@ -1,177 +0,0 @@ -@api @app-required @notifications-app-required @files_sharing-app-required @notToImplementOnOCIS -Feature: Display notifications when receiving a share - As a user - I want to see notifications about shares that have been offered to me - So that I can easily decide what I want to do with new received shares - - Background: - Given app "notifications" has been enabled - And using OCS API version "1" - And using new DAV path - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - And these groups have been created: - | groupname | - | grp1 | - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - - @smokeTest - Scenario: share to user sends notification - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with user "Brian" 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 user "Brian" should have 2 notifications - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - - - Scenario: share to group sends notification to every member - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And user "Alice" shares file "/textfile0.txt" with group "grp1" 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 user "Brian" should have 2 notifications - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 2 notifications - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - - # This scenario documents behavior discussed in core issue 31870 - # An old share keeps its old auto-accept behavior, even after auto-accept has been disabled. - @skipOnLDAP - Scenario: share to group does not send notifications to either existing or new members for an old share created before auto-accept is disabled - Given user "Alice" has shared folder "/PARENT" with group "grp1" - When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "no" - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the OCS status code of responses on each endpoint should be "200, 100" respectively - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should have 0 notifications - And user "Carol" should have 0 notifications - And user "David" should have 0 notifications - - # This scenario documents behavior discussed in core issue 31870 - # As users are added to an existing group, they are not sent notifications about group shares. - @skipOnLDAP - Scenario: share to group sends notifications to existing members, but not to new members, for a share created after auto-accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the OCS status code of responses on each endpoint should be "100, 200, 100" respectively - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should have 1 notification - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 1 notification - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "David" should have 0 notifications - - # This scenario documents behavior discussed in core issue 31870 - # Similar to the previous scenario, a new user added to the group does not get a notification, - # even though the group, when originally created, had notifications on. - @skipOnLDAP - Scenario: share to group sends notifications to existing members, but not to new members, for an old share created before auto-accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with group "grp1" - When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "yes" - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the OCS status code of responses on each endpoint should be "200, 100" respectively - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should have 1 notification - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 1 notification - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "David" should have 0 notifications - - @skipOnLDAP - Scenario: share to group does not send notifications to existing and new members for a share created after auto-accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the OCS status code of responses on each endpoint should be "100, 200, 100" respectively - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should have 0 notifications - And user "Carol" should have 0 notifications - And user "David" should have 0 notifications - - - Scenario: when auto-accepting is enabled no notifications are sent - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with user "Brian" 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 user "Brian" should have 0 notifications - - @skipOnLDAP - Scenario: discard notification if target user is not member of the group anymore - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator removes user "Brian" from group "grp1" using the provisioning 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 user "Brian" should have 0 notifications - And user "Carol" should have 1 notification - - - Scenario: discard notification if group is deleted - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator deletes group "grp1" from the default user backend - 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 user "Brian" should have 0 notifications - And user "Carol" should have 0 notifications diff --git a/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature b/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature deleted file mode 100644 index e5ce35c0d3..0000000000 --- a/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature +++ /dev/null @@ -1,164 +0,0 @@ -@api @app-required @notifications-app-required @files_sharing-app-required @issue-ocis-1328 -Feature: Display notifications when receiving a share - As a user - I want to see notifications about shares that have been offered to me - So that I can easily decide what I want to do with new received shares - - Background: - Given the administrator has set the default folder for received shares to "Shares" - And app "notifications" has been enabled - And using OCS API version "1" - And using new DAV path - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - And these groups have been created: - | groupname | - | grp1 | - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - - @smokeTest - Scenario: share to user sends notification - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should have 2 notifications - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - - - Scenario: share to group sends notification to every member - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And user "Alice" shares file "/textfile0.txt" with group "grp1" 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 user "Brian" should have 2 notifications - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 2 notifications - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - - # This scenario documents behavior discussed in core issue 31870 - # As users are added to an existing group, they are not sent notifications about group shares. - @skipOnLDAP - Scenario: share to group sends notifications to existing members, but not to new members, for a share created after auto-accept is disabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the HTTP status code of responses on all endpoints should be "200" - And the OCS status code of responses on each endpoint should be "100, 200, 100" respectively - And user "Brian" should have 1 notification - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 1 notification - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "David" should have 0 notifications - - # This scenario documents behavior discussed in core issue 31870 - # Similar to the previous scenario, a new user added to the group does not get a notification, - # even though the group, when originally created, had notifications on. - @skipOnLDAP - Scenario: share to group sends notifications to existing members, but not to new members, for an old share created before auto-accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - And user "Alice" has shared folder "/PARENT" with group "grp1" - When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "yes" - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the HTTP status code of responses on all endpoints should be "200" - And the OCS status code of responses on each endpoint should be "200,100" respectively - And user "Brian" should have 1 notification - And the last notification of user "Brian" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "Carol" should have 1 notification - And the last notification of user "Carol" should match these regular expressions about user "Alice" - | key | regex | - | app | /^files_sharing$/ | - | subject | /^"%displayname%" shared "PARENT" with you$/ | - | message | /^"%displayname%" invited you to view "PARENT"$/ | - | link | /^https?:\/\/.+\/f\/(\d+)$/ | - | object_type | /^local_share$/ | - And user "David" should have 0 notifications - - @skipOnLDAP - Scenario: share to group does not send notifications to existing and new members for a share created after auto-accept is enabled - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator creates user "David" using the provisioning API - And the administrator adds user "David" to group "grp1" using the provisioning API - Then the HTTP status code of responses on all endpoints should be "200" - And the OCS status code of responses on each endpoint should be "100, 200, 100" respectively - And user "Brian" should have 0 notifications - And user "Carol" should have 0 notifications - And user "David" should have 0 notifications - - - Scenario: when auto-accepting is enabled no notifications are sent - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API - And user "Alice" shares file "/textfile0.txt" with 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" - And user "Brian" should have 0 notifications - - @skipOnLDAP - Scenario: discard notification if target user is not member of the group anymore - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator removes user "Brian" from group "grp1" using the provisioning 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 user "Brian" should have 0 notifications - And user "Carol" should have 1 notification - - - Scenario: discard notification if group is deleted - Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" - When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API - And the administrator deletes group "grp1" from the default user backend - 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 user "Brian" should have 0 notifications - And user "Carol" should have 0 notifications diff --git a/tests/acceptance/features/coreApiTags/assignTags.feature b/tests/acceptance/features/coreApiTags/assignTags.feature deleted file mode 100644 index 3391b7271c..0000000000 --- a/tests/acceptance/features/coreApiTags/assignTags.feature +++ /dev/null @@ -1,136 +0,0 @@ -@api @systemtags-app-required @files_sharing-app-required @issue-ocis-reva-51 -Feature: Assign tags to file/folder - As a user - I want to assign tags to the file/folder - So that I can organize the files/folders easily - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario: Assigning a normal tag to a file shared by someone else as regular user should work - Given the administrator has created a "normal" tag with name "JustARegularTagName" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - When user "Brian" adds tag "JustARegularTagName" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "201" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | JustARegularTagName | normal | - - - Scenario: Assigning a normal tag to a file belonging to someone else as regular user should fail - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" owned by user "Alice" using the WebDAV API - Then the HTTP status code should be "404" - And file "/myFileToTag.txt" owned by user "Alice" should have the following tags - | name | type | - | MyFirstTag | normal | - - - Scenario: Assigning a not user-assignable tag to a file shared by someone else as regular user should fail - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "not user-assignable" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "403" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | MyFirstTag | normal | - - - Scenario: Assigning a not user-assignable tag to a file shared by someone else as regular user belongs to tag's groups should work - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And the administrator has created a "not user-assignable" tag with name "JustARegularTagName" and groups "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - When user "Brian" adds tag "JustARegularTagName" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "201" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | JustARegularTagName | not user-assignable | - - - Scenario: Assigning a static tag to a file shared by someone else as regular user belongs to tag's groups should work - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And the administrator has created a "static" tag with name "StaticTagName" and groups "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - When user "Brian" adds tag "StaticTagName" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "201" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | StaticTagName | static | - - - Scenario: Assigning a not user-visible tag to a file shared by someone else as regular user should fail - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "not user-visible" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "412" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | MyFirstTag | normal | - - - Scenario: Assigning a static tag to a file shared by someone else as regular user does not belong to tag's group should fail - Given group "hash#group" has been created - And user "Alice" has been added to group "hash#group" - And the administrator has created a "normal" tag with name "NormalTag" - And the administrator has created a "static" tag with name "StaticTag" and groups "hash#group" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has added tag "NormalTag" to file "/myFileToTag.txt" - When user "Brian" adds tag "StaticTag" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "403" - And file "/myFileToTag.txt" shared by user "Alice" should have the following tags - | name | type | - | NormalTag | normal | - - - Scenario: Assigning a not user-visible tag to a file shared by someone else as admin user should work - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "not user-visible" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When the administrator adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "201" - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MyFirstTag | normal | - | MySecondTag | not user-visible | - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MyFirstTag | normal | - - - Scenario: Assigning a not user-assignable tag to a file shared by someone else as admin user should work - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "not user-assignable" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When the administrator adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API - Then the HTTP status code should be "201" - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MyFirstTag | normal | - | MySecondTag | not user-assignable | - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MyFirstTag | normal | - | MySecondTag | not user-assignable | diff --git a/tests/acceptance/features/coreApiTags/assignTagsGroup.feature b/tests/acceptance/features/coreApiTags/assignTagsGroup.feature deleted file mode 100644 index c441aeac6c..0000000000 --- a/tests/acceptance/features/coreApiTags/assignTagsGroup.feature +++ /dev/null @@ -1,29 +0,0 @@ -@api @systemtags-app-required @issue-ocis-reva-51 -Feature: Assign tag to groups - As a user - I should be able to assign tag to groups - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - - Scenario: User can assign tags when in the tag's groups - Given group "grp1" has been created - And user "Alice" has been added to group "grp1" - When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "grp1|group2" using the WebDAV API - Then the HTTP status code should be "201" - And user "Alice" should be able to assign the "not user-assignable" tag with name "TagWithGroups" - - - Scenario: User can assign static tags when in the tag's groups - Given group "grp1" has been created - And user "Alice" has been added to group "grp1" - When the administrator creates a "static" tag with name "TagWithGroups" and groups "grp1|group2" using the WebDAV API - Then the HTTP status code should be "201" - And user "Alice" should be able to assign the "static" tag with name "TagWithGroups" - - - Scenario: User cannot assign tags when not in the tag's groups - When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "grp2|group2" using the WebDAV API - Then the HTTP status code should be "201" - And user "Alice" should not be able to assign the "not user-assignable" tag with name "TagWithGroups" diff --git a/tests/acceptance/features/coreApiTags/createTags.feature b/tests/acceptance/features/coreApiTags/createTags.feature deleted file mode 100644 index d80bb1f1a8..0000000000 --- a/tests/acceptance/features/coreApiTags/createTags.feature +++ /dev/null @@ -1,142 +0,0 @@ -@api @systemtags-app-required @issue-ocis-reva-51 -Feature: Creation of tags - As a user - I should be able to create tags - So that I could categorize my files - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario Outline: Creating a normal tag as regular user should work - When user "Alice" creates a "normal" tag with name "" using the WebDAV API - Then the HTTP status code should be "201" - And the following tags should exist for the administrator - | name | type | - | | normal | - And the following tags should exist for user "Alice" - | name | type | - | | normal | - Examples: - | tag_name | - | JustARegularTagName | - | ЁЯША | - | рд╕рд┐рдордкреНрд▓реЗ | - - - Scenario: Creating a normal tag as a regular user should work (sending the string "1" to turn on the tag attributes) - When user "Alice" creates a "normal" tag with name "RegularTag" sending numbers in the request using the WebDAV API - Then the HTTP status code should be "201" - And the following tags should exist for the administrator - | name | type | - | RegularTag | normal | - And the following tags should exist for user "Alice" - | name | type | - | RegularTag | normal | - - - Scenario: Creating a not user-assignable tag as regular user should fail - When user "Alice" creates a "not user-assignable" tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "400" - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Creating a static tag as regular user should fail - When user "Alice" creates a "static" tag with name "StaticTagName" using the WebDAV API - Then the HTTP status code should be "400" - And tag "StaticTagName" should not exist for the administrator - - - Scenario: Creating a not user-visible tag as regular user should fail - When user "Alice" creates a "not user-visible" tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "400" - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario Outline: Creating a tag as administrator should work - When the administrator creates a "" tag with name "JustARegularTagName" sending in the request using the WebDAV API - Then the HTTP status code should be "201" - And the following tags should exist for the administrator - | name | type | - | JustARegularTagName | | - Examples: - | tag_type | sending_style | - | normal | true-false-strings | - | normal | numbers | - | not user-assignable | true-false-strings | - | not user-assignable | numbers | - | not user-visible | true-false-strings | - | not user-visible | numbers | - | static | true-false-strings | - | static | numbers | - - @smokeTest - Scenario: Creating a not user-assignable tag with groups as admin should work - When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" using the WebDAV API - Then the HTTP status code should be "201" - And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group2" - - - Scenario: Creating a normal tag with groups as regular user should fail - When user "Alice" creates a "normal" tag with name "JustARegularTagName" and groups "group1|group2" using the WebDAV API - Then the HTTP status code should be "400" - And tag "JustARegularTagName" should not exist for user "Alice" - - - Scenario: Creating a normal tag that is already created by other user should fail - Given user "Brian" has created a "normal" tag with name "JustARegularTagName" - When user "Alice" creates a "normal" tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: Overwriting existing normal tags should fail - Given user "Alice" has created a "normal" tag with name "MyFirstTag" - When user "Alice" creates a "normal" tag with name "MyFirstTag" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: Overwriting existing not user-assignable tags should fail - Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" - When the administrator creates a "not user-assignable" tag with name "MyFirstTag" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: Overwriting existing not user-visible tags should fail - Given the administrator has created a "not user-visible" tag with name "MyFirstTag" - When the administrator creates a "not user-visible" tag with name "MyFirstTag" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: Overwriting existing static tags should fail - Given the administrator has created a "static" tag with name "StaticTag" - When the administrator creates a "static" tag with name "StaticTag" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: Creating tags in lowercase and uppercase should work - When the administrator creates the following tags using the WebDAV API - | name | type | - | UppercaseTag | normal | - | lowercasetag | normal | - Then the HTTP status code of responses on all endpoints should be "201" - And the following tags should exist for the administrator - | name | type | - | UppercaseTag | normal | - | lowercasetag | normal | - - - Scenario: Creating tags with the same name in lowercase and uppercase should work - When the administrator creates the following tags using the WebDAV API - | name | type | - | testtag | normal | - | Testtag | normal | - | TESTTAG | normal | - Then the HTTP status code of responses on all endpoints should be "201" - And the following tags should exist for the administrator - | name | type | - | testtag | normal | - | Testtag | normal | - | TESTTAG | normal | diff --git a/tests/acceptance/features/coreApiTags/deleteTags.feature b/tests/acceptance/features/coreApiTags/deleteTags.feature deleted file mode 100644 index ef12857452..0000000000 --- a/tests/acceptance/features/coreApiTags/deleteTags.feature +++ /dev/null @@ -1,72 +0,0 @@ -@api @systemtags-app-required @issue-ocis-reva-51 -Feature: Deletion of tags - As a user - I want to delete the tags that are already created - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @smokeTest - Scenario: Deleting a normal tag as regular user should work - Given the administrator has created a "normal" tag with name "JustARegularTagName" - When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "204" - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Deleting a normal tag that has already been assigned to a file should work - Given user "Alice" has created a "normal" tag with name "JustARegularTagName" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has added tag "JustARegularTagName" to file "/myFileToTag.txt" - When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "204" - And tag "JustARegularTagName" should not exist for the administrator - And file "/myFileToTag.txt" should have no tags for user "Alice" - - - Scenario: Deleting a not user-assignable tag as regular user should fail - Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" - When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "403" - And the following tags should exist for the administrator - | name | type | - | JustARegularTagName | not user-assignable | - - - Scenario: Deleting a not user-visible tag as regular user should fail - Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" - When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "404" - And the following tags should exist for the administrator - | name | type | - | JustARegularTagName | not user-visible | - - - Scenario: Deleting a static tag as regular user should fail - Given the administrator has created a "static" tag with name "StaticTagName" - When user "Alice" deletes the tag with name "StaticTagName" using the WebDAV API - Then the HTTP status code should be "403" - And the following tags should exist for the administrator - | name | type | - | StaticTagName | static | - - - Scenario: Deleting a not user-assignable tag as admin should work - Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" - When the administrator deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "204" - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Deleting a not user-visible tag as admin should work - Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" - When the administrator deletes the tag with name "JustARegularTagName" using the WebDAV API - Then the HTTP status code should be "204" - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Deleting a static tag as admin should work - Given the administrator has created a "static" tag with name "StaticTagName" - When the administrator deletes the tag with name "StaticTagName" using the WebDAV API - Then the HTTP status code should be "204" - And tag "StaticTagName" should not exist for the administrator diff --git a/tests/acceptance/features/coreApiTags/editTags.feature b/tests/acceptance/features/coreApiTags/editTags.feature deleted file mode 100644 index f548976145..0000000000 --- a/tests/acceptance/features/coreApiTags/editTags.feature +++ /dev/null @@ -1,99 +0,0 @@ -@api @systemtags-app-required @issue-ocis-reva-51 -Feature: Editing the tags - As a user - I want to be able to change the tags I have created - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @smokeTest - Scenario Outline: Renaming a normal tag as regular user should work - Given the administrator has created a "normal" tag with name "" - When user "Alice" edits the tag with name "" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "207" - And the following tags should exist for the administrator - | name | type | - | AnotherTagName | normal | - Examples: - | tag_name | - | JustARegularTagName | - | ЁЯША | - | рд╕рд┐рдордкреНрд▓реЗ | - - - Scenario: Renaming a not user-assignable tag as regular user should fail - Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" - When user "Alice" edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "403" - And the following tags should exist for the administrator - | name | type | - | JustARegularTagName | not user-assignable | - - - Scenario: Renaming a static tag as regular user should fail - Given the administrator has created a "static" tag with name "StaticTagName" - When user "Alice" edits the tag with name "StaticTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "403" - And the following tags should exist for the administrator - | name | type | - | StaticTagName | static | - - - Scenario: Renaming a not user-visible tag as regular user should fail - Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" - When user "Alice" edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "404" - And the following tags should exist for the administrator - | name | type | - | JustARegularTagName | not user-visible | - - - Scenario: Renaming a not user-assignable tag as administrator should work - Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" - When the administrator edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "207" - And the following tags should exist for the administrator - | name | type | - | AnotherTagName | not user-assignable | - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Renaming a not user-visible tag as administrator should work - Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" - When the administrator edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "207" - And the following tags should exist for the administrator - | name | type | - | AnotherTagName | not user-visible | - And tag "JustARegularTagName" should not exist for the administrator - - - Scenario: Renaming a static tag as administrator should work - Given the administrator has created a "static" tag with name "StaticTagName" - When the administrator edits the tag with name "StaticTagName" and sets its name to "AnotherTagName" using the WebDAV API - Then the HTTP status code should be "207" - And the following tags should exist for the administrator - | name | type | - | AnotherTagName | static | - And tag "StaticTagName" should not exist for the administrator - - - Scenario: Editing tag groups as admin should work - Given the administrator has created a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" - When the administrator edits the tag with name "TagWithGroups" and sets its groups to "group1|group3" using the WebDAV API - Then the HTTP status code should be "207" - And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group3" - - - Scenario: Editing static tag groups as admin should work - Given the administrator has created a "static" tag with name "StaticTagWithGroups" and groups "group1|group2" - When the administrator edits the tag with name "StaticTagWithGroups" and sets its groups to "group1|group3" using the WebDAV API - Then the HTTP status code should be "207" - And the "static" tag with name "StaticTagWithGroups" should have the groups "group1|group3" - - - Scenario: Editing tag groups as regular user should fail - Given the administrator has created a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" - When user "Alice" edits the tag with name "TagWithGroups" and sets its groups to "group1|group3" using the WebDAV API - Then the HTTP status code should be "403" - And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group2" diff --git a/tests/acceptance/features/coreApiTags/retreiveTags.feature b/tests/acceptance/features/coreApiTags/retreiveTags.feature deleted file mode 100644 index 857d0f82a6..0000000000 --- a/tests/acceptance/features/coreApiTags/retreiveTags.feature +++ /dev/null @@ -1,31 +0,0 @@ -@api @systemtags-app-required @issue-ocis-reva-51 -Feature: tags - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario: Getting tags only works with access to the file - Given the administrator has created a "normal" tag with name "MyFirstTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - When user "Brian" requests tags for file "/myFileToTag.txt" owned by user "Alice" using the WebDAV API - And user "Alice" gets the following properties of file "/myFileToTag.txt" using the WebDAV API - | propertyName | - | oc:tags | - Then the HTTP status code of responses on all endpoints should be "404" - And the single response should contain a property "oc:tags" with value "" - - @files_sharing-app-required - Scenario: Static tags should be available while accessing the file if it is assigned to file - Given the administrator has created a "static" tag with name "StaticTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - When the administrator adds tag "StaticTag" to file "/myFileToTag.txt" using the WebDAV API - Then file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | StaticTag | static | - And the HTTP status when user "Brian" requests tags for file "/myFileToTag.txt" owned by user "Alice" should be "404" diff --git a/tests/acceptance/features/coreApiTags/unassignTags.feature b/tests/acceptance/features/coreApiTags/unassignTags.feature deleted file mode 100644 index b220936779..0000000000 --- a/tests/acceptance/features/coreApiTags/unassignTags.feature +++ /dev/null @@ -1,177 +0,0 @@ -@api @systemtags-app-required @files_sharing-app-required @issue-ocis-reva-51 -Feature: Unassigning tags from file/folder - As a user - I want to be able to remove tags from file/folder - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - @smokeTest - Scenario: Unassigning a normal tag from a file shared by someone else as regular user should work - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - - - Scenario: Unassigning a normal tag from a file unshared by someone else as regular user should fail - Given the administrator has created a "normal" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "404" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MyFirstTag | normal | - | MySecondTag | normal | - - - Scenario: Unassigning a not user-visible tag from a file shared by someone else as regular user should fail - Given the administrator has created a "not user-visible" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "404" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MyFirstTag | not user-visible | - | MySecondTag | normal | - - - Scenario: Unassigning a static tag from a file and not part of static tags group shared by someone else as regular user should fail - Given the administrator has created a "static" tag with name "StaticTag" - And user "Alice" has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "StaticTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When user "Brian" removes tag "StaticTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - | StaticTag | static | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | StaticTag | static | - | MySecondTag | normal | - - - Scenario: Unassigning a not user-visible tag from a file shared by someone else as admin should work - Given the administrator has created a "not user-visible" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MySecondTag | normal | - - - Scenario: Unassigning a static tag from a file shared by someone else as admin should work - Given the administrator has created a "static" tag with name "StaticTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "StaticTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When the administrator removes tag "StaticTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MySecondTag | normal | - - - Scenario: Unassigning a not user-visible tag from a file unshared by someone else should fail - Given the administrator has created a "not user-visible" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - And user "Alice" has removed all shares from the file named "/myFileToTag.txt" - When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "404" - - - Scenario: Unassigning a not user-assignable tag from a file shared by someone else as regular user should fail - Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MyFirstTag | not user-assignable | - | MySecondTag | normal | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MyFirstTag | not user-assignable | - | MySecondTag | normal | - - - Scenario: Unassigning a not user-assignable tag from a file shared by someone else as admin should work - Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And file "/myFileToTag.txt" should have the following tags for user "Alice" - | name | type | - | MySecondTag | normal | - And file "/myFileToTag.txt" should have the following tags for the administrator - | name | type | - | MySecondTag | normal | - - - Scenario: Unassigning a not user-assignable tag from a file unshared by someone else should fail - Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" - And the administrator has created a "normal" tag with name "MySecondTag" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" - And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" - And user "Alice" has shared file "/myFileToTag.txt" with the administrator - And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" - And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" - And user "Alice" has removed all shares from the file named "/myFileToTag.txt" - When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API - Then the HTTP status code should be "404" diff --git a/tests/acceptance/run.sh b/tests/acceptance/run.sh index 2808a9ae26..5eae841c11 100755 --- a/tests/acceptance/run.sh +++ b/tests/acceptance/run.sh @@ -29,9 +29,6 @@ fi # BEHAT_FILTER_TAGS - see "--tags" description # BEHAT_SUITE - see "--suite" description # BEHAT_YML - see "--config" description -# BROWSER - see "--browser" description -# NORERUN - see "--norerun" description -# RERUN_FAILED_WEBUI_SCENARIOS - opposite of NORERUN # RUN_PART and DIVIDE_INTO_NUM_PARTS - see "--part" description # SHOW_OC_LOGS - see "--show-oc-logs" description # TESTING_REMOTE_SYSTEM - see "--remote" description @@ -62,15 +59,12 @@ fi # -c or --config - specify a behat.yml to use # --feature - specify a single feature to run # --suite - specify a single suite to run -# --type - api, cli or webui - if no individual feature or suite is specified, then +# --type - api or core-api - if no individual feature or suite is specified, then # specify the type of acceptance tests to run. Default api. # --tags - specify tags for scenarios to run (or not) -# --browser - for webUI tests, which browser to use. "chrome", "firefox", -# "internet explorer" and "MicrosoftEdge" are possible. # --remote - the server under test is remote, so we cannot locally enable the # testing app. We have to assume it is already enabled. # --show-oc-logs - tail the ownCloud log after the test run -# --norerun - do not rerun failed webUI scenarios # --loop - loop tests for given number of times. Only use it for debugging purposes # --part - run a subset of scenarios, need two numbers. # first number: which part to run @@ -100,7 +94,7 @@ do shift ;; --type) - # Lowercase the parameter value, so the user can provide "API", "CLI", "webUI" etc + # Lowercase the parameter value, so the user can provide "API", "CORE-API", etc ACCEPTANCE_TEST_TYPE="${2,,}" shift ;; @@ -109,10 +103,6 @@ do BEHAT_TAGS_OPTION_FOUND=true shift ;; - --browser) - BROWSER="$2" - shift - ;; --part) RUN_PART="$2" DIVIDE_INTO_NUM_PARTS="$3" @@ -123,9 +113,6 @@ do fi shift 2 ;; - --norerun) - RERUN_FAILED_WEBUI_SCENARIOS=false - ;; --step-through) STEP_THROUGH_OPTION="--step-through" ;; @@ -173,8 +160,6 @@ fi # $TEST_LOG_FILE # $BEHAT - behat executable # $BEHAT_YML -# $RUNNING_WEBUI_TESTS -# $RERUN_FAILED_WEBUI_SCENARIOS # # set arrays # --------------- @@ -356,69 +341,6 @@ function run_behat_tests() { UNEXPECTED_BEHAT_EXIT_STATUSES+=("${SUITE_FEATURE_TEXT} had behat exit status ${BEHAT_EXIT_STATUS}") fi - # With webUI tests, we try running failed tests again. - if [ ${#UNEXPECTED_FAILED_SCENARIOS[@]} -gt 0 ] && [ "${RUNNING_WEBUI_TESTS}" = true ] && [ "${RERUN_FAILED_WEBUI_SCENARIOS}" = true ] - then - echo "webUI test run failed with exit status: ${BEHAT_EXIT_STATUS}" - FAILED_SCENARIO_PATHS_COLORED=`awk '/Failed scenarios:/',0 ${TEST_LOG_FILE} | grep feature` - # There will be some ANSI escape codes for color in the FEATURE_COLORED var. - # Strip them out so we can pass just the ordinary feature details to Behat. - # Thanks to https://en.wikipedia.org/wiki/Tee_(command) and - # https://stackoverflow.com/questions/23416278/how-to-strip-ansi-escape-sequences-from-a-variable - # for ideas. - FAILED_SCENARIO_PATHS=$(echo "${FAILED_SCENARIO_PATHS_COLORED}" | sed "s/\x1b[^m]*m//g") - - # If something else went wrong, and there were no failed scenarios, - # then the awk, grep, sed command sequence above ends up with an empty string. - # Unset FAILED_SCENARIO_PATHS to avoid later code thinking that there might be - # one failed scenario. - if [ -z "${FAILED_SCENARIO_PATHS}" ] - then - unset FAILED_SCENARIO_PATHS - FAILED_SCENARIO_PATHS=() - fi - - for FAILED_SCENARIO_PATH in ${FAILED_SCENARIO_PATHS} - do - SUITE_PATH=`dirname ${FAILED_SCENARIO_PATH}` - SUITE=`basename ${SUITE_PATH}` - SCENARIO=`basename ${FAILED_SCENARIO_PATH}` - SUITE_SCENARIO="${SUITE}/${SCENARIO}" - - if [ -n "${EXPECTED_FAILURES_FILE}" ] - then - grep -x ${SUITE_SCENARIO} ${EXPECTED_FAILURES_FILE} > /dev/null - if [ $? -eq 0 ] - then - echo "Notice: Scenario ${SUITE_SCENARIO} is expected to fail so do not rerun it." - continue - fi - fi - - echo "Rerun failed scenario: ${FAILED_SCENARIO_PATH}" - ${BEHAT} --colors --strict -c ${BEHAT_YML} -f pretty ${BEHAT_SUITE_OPTION} --tags ${BEHAT_FILTER_TAGS} ${FAILED_SCENARIO_PATH} -v 2>&1 | tee -a ${TEST_LOG_FILE} - BEHAT_EXIT_STATUS=${PIPESTATUS[0]} - if [ ${BEHAT_EXIT_STATUS} -eq 0 ] - then - # The scenario was not expected to fail but had failed and is present in the - # unexpected_failures list. We've checked the scenario with a re-run and - # it passed. So remove it from the unexpected_failures list. - for i in "${!UNEXPECTED_FAILED_SCENARIOS[@]}" - do - if [ "${UNEXPECTED_FAILED_SCENARIOS[i]}" == "$SUITE_SCENARIO" ] - then - unset "UNEXPECTED_FAILED_SCENARIOS[i]" - fi - done - else - echo "webUI test rerun failed with exit status: ${BEHAT_EXIT_STATUS}" - # The scenario is not expected to fail but is failing also after the rerun. - # Since it is already reported in the unexpected_failures list, there is no - # need to touch that again. Continue processing the next scenario to rerun. - fi - done - fi - if [ "${BEHAT_TAGS_OPTION_FOUND}" != true ] then # The behat run specified to skip scenarios tagged @skip @@ -484,48 +406,59 @@ ACCEPTANCE_DIR=$(dirname "${BEHAT_CONFIG_DIR}") BEHAT_FEATURES_DIR="${ACCEPTANCE_DIR}/features" declare -a BEHAT_SUITES + +function get_behat_suites() { + # $1 type of suites to get "api" or "core-api" + # defaults to "api" + TYPE="$1" + if [[ -z "$TYPE" ]] + then + TYPE="api" + fi + ALL_SUITES=`find ${BEHAT_FEATURES_DIR}/ -type d -iname ${TYPE}* | sort | rev | cut -d"/" -f1 | rev` + COUNT_ALL_SUITES=`echo "${ALL_SUITES}" | wc -l` + #divide the suites letting it round down (could be zero) + MIN_SUITES_PER_RUN=$((${COUNT_ALL_SUITES} / ${DIVIDE_INTO_NUM_PARTS})) + #some jobs might need an extra suite + MAX_SUITES_PER_RUN=$((${MIN_SUITES_PER_RUN} + 1)) + # the remaining number of suites that need to be distributed (could be zero) + REMAINING_SUITES=$((${COUNT_ALL_SUITES} - (${DIVIDE_INTO_NUM_PARTS} * ${MIN_SUITES_PER_RUN}))) + + if [[ ${RUN_PART} -le ${REMAINING_SUITES} ]] + then + SUITES_THIS_RUN=${MAX_SUITES_PER_RUN} + SUITES_IN_PREVIOUS_RUNS=$((${MAX_SUITES_PER_RUN} * (${RUN_PART} - 1))) + else + SUITES_THIS_RUN=${MIN_SUITES_PER_RUN} + SUITES_IN_PREVIOUS_RUNS=$((((${MAX_SUITES_PER_RUN} * ${REMAINING_SUITES}) + (${MIN_SUITES_PER_RUN} * (${RUN_PART} - ${REMAINING_SUITES} - 1))))) + fi + + if [ ${SUITES_THIS_RUN} -eq 0 ] + then + echo "there are only ${COUNT_ALL_SUITES} suites, nothing to do in part ${RUN_PART}" + exit 0 + fi + + COUNT_FINISH_AND_TODO_SUITES=$((${SUITES_IN_PREVIOUS_RUNS} + ${SUITES_THIS_RUN})) + BEHAT_SUITES+=(`echo "${ALL_SUITES}" | head -n ${COUNT_FINISH_AND_TODO_SUITES} | tail -n ${SUITES_THIS_RUN}`) +} + if [[ -n "${BEHAT_SUITE}" ]] then - BEHAT_SUITES+=(${BEHAT_SUITE}) + BEHAT_SUITES+=("${BEHAT_SUITE}") else - if [[ -n "${RUN_PART}" ]] + if [[ -n "${RUN_PART}" && "${ACCEPTANCE_TEST_TYPE}" == "core-api" ]] then - ALL_SUITES=`find ${BEHAT_FEATURES_DIR}/ -type d -iname ${ACCEPTANCE_TEST_TYPE}* | sort | rev | cut -d"/" -f1 | rev` - COUNT_ALL_SUITES=`echo "${ALL_SUITES}" | wc -l` - #divide the suites letting it round down (could be zero) - MIN_SUITES_PER_RUN=$((${COUNT_ALL_SUITES} / ${DIVIDE_INTO_NUM_PARTS})) - #some jobs might need an extra suite - MAX_SUITES_PER_RUN=$((${MIN_SUITES_PER_RUN} + 1)) - # the remaining number of suites that need to be distributed (could be zero) - REMAINING_SUITES=$((${COUNT_ALL_SUITES} - (${DIVIDE_INTO_NUM_PARTS} * ${MIN_SUITES_PER_RUN}))) - - if [[ ${RUN_PART} -le ${REMAINING_SUITES} ]] - then - SUITES_THIS_RUN=${MAX_SUITES_PER_RUN} - SUITES_IN_PREVIOUS_RUNS=$((${MAX_SUITES_PER_RUN} * (${RUN_PART} - 1))) - else - SUITES_THIS_RUN=${MIN_SUITES_PER_RUN} - SUITES_IN_PREVIOUS_RUNS=$((((${MAX_SUITES_PER_RUN} * ${REMAINING_SUITES}) + (${MIN_SUITES_PER_RUN} * (${RUN_PART} - ${REMAINING_SUITES} - 1))))) - fi - - if [ ${SUITES_THIS_RUN} -eq 0 ] - then - echo "there are only ${COUNT_ALL_SUITES} suites, nothing to do in part ${RUN_PART}" - exit 0 - fi - - COUNT_FINISH_AND_TODO_SUITES=$((${SUITES_IN_PREVIOUS_RUNS} + ${SUITES_THIS_RUN})) - BEHAT_SUITES+=(`echo "${ALL_SUITES}" | head -n ${COUNT_FINISH_AND_TODO_SUITES} | tail -n ${SUITES_THIS_RUN}`) + get_behat_suites "core" + else + get_behat_suites "${ACCEPTANCE_TEST_TYPE}" fi fi TEST_TYPE_TAG="@api" TEST_TYPE_TEXT="API" -RUNNING_API_TESTS=true -RUNNING_CLI_TESTS=false -RUNNING_WEBUI_TESTS=false -# Always have one of "@api", "@cli" or "@webUI" filter tags +# Always have "@api" if [ -z "${BEHAT_FILTER_TAGS}" ] then BEHAT_FILTER_TAGS="${TEST_TYPE_TAG}" @@ -559,36 +492,6 @@ then EMAIL_SMTP_PORT="2500" fi -if [ -z "${SELENIUM_HOST}" ] -then - SELENIUM_HOST=localhost -fi - -if [ -z "${SELENIUM_PORT}" ] -then - SELENIUM_PORT=4445 -fi - -if [ -z "${BROWSER}" ] -then - BROWSER="chrome" -fi - -# table of settings to be remembered and set -#system|app;app-name;setting-name;value;variable-type -declare -a SETTINGS -SETTINGS+=("system;;mail_domain;foobar.com") -SETTINGS+=("system;;mail_from_address;owncloud") -SETTINGS+=("system;;mail_smtpmode;smtp") -SETTINGS+=("system;;mail_smtphost;${EMAIL_HOST}") -SETTINGS+=("system;;mail_smtpport;${EMAIL_SMTP_PORT}") -SETTINGS+=("app;core;backgroundjobs_mode;webcron") -SETTINGS+=("system;;sharing.federation.allowHttpFallback;true;boolean") -SETTINGS+=("system;;grace_period.demo_key.show_popup;false;boolean") -SETTINGS+=("app;core;enable_external_storage;yes") -SETTINGS+=("system;;files_external_allow_create_new_local;true") -SETTINGS+=("system;;skeletondirectory;;") - # If the caller did not mention specific tags, skip the skipped tests by default if [ "${BEHAT_TAGS_OPTION_FOUND}" = false ] then